From paulej@packetizer.com Fri Feb 1 07:14:52 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 1509E21E8030 for ; Fri, 1 Feb 2013 07:14:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.264 X-Spam-Level: X-Spam-Status: No, score=-1.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7eFpOe1fmaJV for ; Fri, 1 Feb 2013 07:14:51 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 08E0911E8099 for ; Fri, 1 Feb 2013 07:14:50 -0800 (PST) Received: from [10.62.146.233] (mobile-032-151-055-199.mycingular.net [32.151.55.199] (may be forged)) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r11FEiZA007153 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 1 Feb 2013 10:14:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1359731688; bh=9jBc4R0HAXIfIPT/3F7nqOiWNss/2/ciLVIYEJRTaYo=; h=In-Reply-To:References:MIME-Version:Content-Type:Subject:From: Date:To:CC:Message-ID; b=Ilpy/BY1G/xidwXP4p4hhdlSniAaHYoVyIREE3HxLlSjwrKHwxbvstG7J0vhhVBWZ U7dQNUbcsl5bKW5x3Ey6efivyQLajVW3h/UqU4lB3bFmSQ5YYLrZcdTzLpTyr1zrNY DMIausFnbEPt+bpP0Nmv1WIM6Jz5OhI5Mxw1Dw/U= User-Agent: K-9 Mail for Android In-Reply-To: References: <5106BFDC.2030706@ericsson.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----WBMMH33ZFA9WOZU630SK62MF8XT13R" From: "Paul E. Jones" Date: Fri, 01 Feb 2013 10:14:39 -0500 To: Melvin Carvalho , Salvatore Loreto Message-ID: <976e3f7b-3173-4ceb-9b6e-7fb7d9128bfd@email.android.com> Cc: webfinger@ietf.org, "Murray S. Kucherawy" Subject: Re: [webfinger] Working Group Last Call for draft-ietf-appsawg-webfinger-09 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, 01 Feb 2013 15:14:52 -0000 ------WBMMH33ZFA9WOZU630SK62MF8XT13R Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Mervin, What would be the reason? There are tons of applications that return JSON, but they don't each have their own media type. We did that with XML and have tons of media types, ask of which are just XML documents. What is preferred by others? My preference is to leave it as defined. Clients know what the response is. Paul -------- Original Message -------- From: Melvin Carvalho Sent: Tue Jan 29 13:40:38 EST 2013 To: Salvatore Loreto Cc: webfinger@ietf.org, "Murray S. Kucherawy" Subject: Re: [webfinger] Working Group Last Call for draft-ietf-appsawg-webfinger-09 On 28 January 2013 19:13, Salvatore Loreto wrote: > Dear WG partecipants, > > > I would like to initiate a 2 weeks WG Last Call on > draft-ietf-appsawg-webfinger-09.txt ("WebFinger") > http://tools.ietf.org/id/draft-ietf-appsawg-webfinger-09.txt > > > Please send your reviews, as well as expression of support regarding > document readiness for IESG (or not) either to the **webfinger** mailing > list (webfinger@ietf.org), > or directly to the WG chairs (Murray Kucherawy and myself). > > Comments like "I've read the document and it is Ok to publish" or > "I've read the document and it has the following issues" > are useful and would be gratefully accepted by chairs. > I have read the document and I think the JRD should have it's own MIME type, which the client SHOULD send with the HTTP(S) GET. > > > The WG LC will end on Friday, February 8th. > > > Thank you, > Salvatore as an APPSAWG co-chair. > > > > _______________________________________________ > 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 ------WBMMH33ZFA9WOZU630SK62MF8XT13R Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Mervin,

What would be the reason? There are tons of applications that return JSON, but they don't each have their own media type. We did that with XML and have tons of media types, ask of which are just XML documents.

What is preferred by others? My preference is to leave it as defined. Clients know what the response is.

Paul

From: Melvin Carvalho <melvincarvalho@gmail.com>
Sent: Tue Jan 29 13:40:38 EST 2013
To: Salvatore Loreto <salvatore.loreto@ericsson.com>
Cc: webfinger@ietf.org, "Murray S. Kucherawy" <superuser@gmail.com>
Subject: Re: [webfinger] Working Group Last Call for draft-ietf-appsawg-webfinger-09



On 28 January 2013 19:13, Salvatore Loreto <salvatore.loreto@ericsson.com> wrote:
Dear WG partecipants,


I would like to initiate a 2 weeks WG Last Call on
draft-ietf-appsawg-webfinger-09.txt ("WebFinger")
http://tools.ietf.org/id/draft-ietf-appsawg-webfinger-09.txt


Please send your reviews, as well as expression of support regarding
document readiness for IESG (or not) either to the *webfinger* mailing list (webfinger@ietf.org),
or directly to the WG chairs (Murray Kucherawy and myself).

Comments like "I've read the document and it is Ok to publish" or
"I've read the document and it has the following issues"
are useful and would be gratefully accepted by chairs.

I have read the document and I think the JRD should have it's own MIME type, which the client SHOULD send with the HTTP(S) GET. 
 


The WG LC will end on Friday, February 8th.


Thank you,
Salvatore as an APPSAWG co-chair.



_______________________________________________
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
------WBMMH33ZFA9WOZU630SK62MF8XT13R-- From melvincarvalho@gmail.com Fri Feb 1 07:30: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 1D4F421E8047 for ; Fri, 1 Feb 2013 07:30:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TGjWO-D04DRW for ; Fri, 1 Feb 2013 07:30:58 -0800 (PST) Received: from mail-ia0-x22f.google.com (ia-in-x022f.1e100.net [IPv6:2607:f8b0:4001:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 001D921E8030 for ; Fri, 1 Feb 2013 07:30:57 -0800 (PST) Received: by mail-ia0-f175.google.com with SMTP id r4so5389773iaj.20 for ; Fri, 01 Feb 2013 07:30:57 -0800 (PST) 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=GkW7sl/+NNTVqGEvvNlIiIkPeBJ3jfg4GQZjkmyHttE=; b=T3ZK/alhiXzsw5hkniu13bIUjjJNopEdJF/JVO1352nZS6tFzxtwU+luPhwYPt95p5 v2RClzqvxN/qioV/Fz0GQW2HTLAHV/cLzMdgXRJw4gAtNL+WhOaEjcCuscAXHv9QhgOM mNBpy9Tr1LvIZEJ/HNBjl3vlJx363z7eDRQ81+J1VepWYNLmqdFgAQNTyBvnZeRtDG3g PnmsAqYfeCQPg0Te5SBeov80whIr8hk3p6Nf1BIFnpBjZZTum0BYK7FW9rb0HYGmj7I0 C6dTsCVsm5Hl/BPQnjnDcgiG/rTE6Z+U7M0QdssMz3mer0ibZNSyI/F2TXhVFk81lu41 8blQ== MIME-Version: 1.0 X-Received: by 10.50.77.230 with SMTP id v6mr1428120igw.11.1359732657088; Fri, 01 Feb 2013 07:30:57 -0800 (PST) Received: by 10.43.101.5 with HTTP; Fri, 1 Feb 2013 07:30:56 -0800 (PST) In-Reply-To: <976e3f7b-3173-4ceb-9b6e-7fb7d9128bfd@email.android.com> References: <5106BFDC.2030706@ericsson.com> <976e3f7b-3173-4ceb-9b6e-7fb7d9128bfd@email.android.com> Date: Fri, 1 Feb 2013 16:30:56 +0100 Message-ID: From: Melvin Carvalho To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=e89a8f3ba87f03e94704d4ab6eef Cc: Salvatore Loreto , webfinger@ietf.org, "Murray S. Kucherawy" Subject: Re: [webfinger] Working Group Last Call for draft-ietf-appsawg-webfinger-09 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, 01 Feb 2013 15:30:59 -0000 --e89a8f3ba87f03e94704d4ab6eef Content-Type: text/plain; charset=ISO-8859-1 On 1 February 2013 16:14, Paul E. Jones wrote: > Mervin, > > What would be the reason? There are tons of applications that return JSON, > but they don't each have their own media type. We did that with XML and > have tons of media types, ask of which are just XML documents. > > What is preferred by others? My preference is to leave it as defined. > Clients know what the response is. > Examining Eran's original post on JRD has it's own MIME type, which I believe was always the intention: Accept: application/xrd+json http://hueniverse.com/2010/05/jrd-the-other-resource-descriptor/#comment-8122 In previous discussions, at least one person (I think it may have been Tim Bray) has stated that this represents a best practice. There are many JSON serializations out there, with JRD being relatively bespoke. A MIME type would help the client understand what data it is getting without close coupling to the URL that returned it, and also would aid interoperability with other formats, in particular, many implementations still use XRD, which uses (application/xrd+xml) > Paul > > ------------------------------ > *From:* Melvin Carvalho > *Sent:* Tue Jan 29 13:40:38 EST 2013 > *To:* Salvatore Loreto > *Cc:* webfinger@ietf.org, "Murray S. Kucherawy" > *Subject:* Re: [webfinger] Working Group Last Call for > draft-ietf-appsawg-webfinger-09 > > > > On 28 January 2013 19:13, Salvatore Loreto wrote: > >> Dear WG partecipants, >> >> >> I would like to initiate a 2 weeks WG Last Call on >> draft-ietf-appsawg-webfinger-09.txt ("WebFinger") >> http://tools.ietf.org/id/draft-ietf-appsawg-webfinger-09.txt >> >> >> Please send your reviews, as well as expression of support regarding >> document readiness for IESG (or not) either to the **webfinger** mailing >> list (webfinger@ietf.org), >> or directly to the WG chairs (Murray Kucherawy and myself). >> >> Comments like "I've read the document and it is Ok to publish" or >> "I've read the document and it has the following issues" >> are useful and would be gratefully accepted by chairs. >> > > I have read the document and I think the JRD should have it's own MIME > type, which the client SHOULD send with the HTTP(S) GET. > > >> >> >> The WG LC will end on Friday, February 8th. >> >> >> Thank you, >> Salvatore as an APPSAWG co-chair. >> >> >> >> _______________________________________________ >> 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 > > --e89a8f3ba87f03e94704d4ab6eef Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 1 February 2013 16:14, Paul E. Jones = <paulej@packetizer.com> wrote:
Mervin,

What would be the reason? There are tons of applications that return JSON, = but they don't each have their own media type. We did that with XML and= have tons of media types, ask of which are just XML documents.

What is preferred by others? My preference is to leave it as defined. Clien= ts know what the response is.

Examinin= g Eran's original post on JRD has it's own MIME type, which I belie= ve was always the intention:

Accept: application/xrd+json

http://hueniverse.co= m/2010/05/jrd-the-other-resource-descriptor/#comment-8122

In pre= vious discussions, at least one person (I think it may have been Tim Bray) = has stated that this represents a best practice.

There are many JSON serializations out there, with JRD being relatively= bespoke.=A0

A MIME type would help the client understand what data= it is getting without close coupling to the URL that returned it, and also= would aid interoperability with other formats, in particular, many impleme= ntations still use XRD, which uses (application/xrd+xml)


Paul

From: Melvin Carvalho <melvincarvalho@gmail.com>
Sent: Tue Jan 29 13:40:38 EST 2013
To: Salvatore Loreto <salvatore.loreto@ericsson.com>
Cc: webfinge= r@ietf.org, "Murray S. Kucherawy" <superuser@gmail.com>
Subject: Re: [webfinger] Working Group Last Call for draft-ietf-apps= awg-webfinger-09



On 28 January 2013 19:13, Salvatore Lore= to <salvatore.loreto@ericsson.com> wrote:
=20 =20 =20
Dear WG partecipants,


I would like to initiate a 2 weeks WG Last Call on
draft-ietf-appsawg-webfinger-09.txt ("WebFinger")
http://tools.ietf.org/id/draft-ietf-appsawg-webfinger-09= .txt


Please send your reviews, as well as expression of support regarding
document readiness for IESG (or not) either to the *web= finger* mailing list (webfinger@ietf= .org),
or directly to the WG chairs (Murray Kucherawy and myself).

Comments like "I've read the document and it is Ok to publish&= quot; or
"I've read the document and it has the following issues"<= br> are useful and would be gratefully accepted by chairs.

I have read the document and I think th= e JRD should have it's own MIME type, which the client SHOULD send with= the HTTP(S) GET.=A0
=A0


The WG LC will end on Friday, February 8th.


Thank you,
Salvatore as an APPSAWG co-chair.



_______________________________________________
webfinger mailing list
webfinger@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/webfinger



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

--e89a8f3ba87f03e94704d4ab6eef-- From salvatore.loreto@ericsson.com Fri Feb 1 08:19:06 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 7002821E8039 for ; Fri, 1 Feb 2013 08:19:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.248 X-Spam-Level: X-Spam-Status: No, score=-106.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DuKE5MUdUAUj for ; Fri, 1 Feb 2013 08:19:05 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 38C8921E8082 for ; Fri, 1 Feb 2013 08:19:05 -0800 (PST) X-AuditID: c1b4fb25-b7f366d000004d10-80-510beaf8b66c Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id A6.A4.19728.8FAEB015; Fri, 1 Feb 2013 17:19:04 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Fri, 1 Feb 2013 17:19:03 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 81F582AD9 for ; Fri, 1 Feb 2013 18:19:03 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 8979B54098 for ; Fri, 1 Feb 2013 18:19:01 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 31A0153473 for ; Fri, 1 Feb 2013 18:19:01 +0200 (EET) Message-ID: <510BEAF6.8000008@ericsson.com> Date: Fri, 1 Feb 2013 18:19:02 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: webfinger@ietf.org References: <5106BFDC.2030706@ericsson.com> In-Reply-To: <5106BFDC.2030706@ericsson.com> Content-Type: multipart/alternative; boundary="------------030501070701000906020204" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJLMWRmVeSWpSXmKPExsUyM+Jvre6PV9yBBrsu8VssujGd0YHRY8mS n0wBjFFcNimpOZllqUX6dglcGftOTmEq2KJY0bnyBXsDY5dUFyMnh4SAicT+M/+ZIWwxiQv3 1rN1MXJxCAmcZJRobXwM5axnlNhwYhMjhHOZUeLDkVYmCOcYo8Sr0+egnPOMEv8OH2MFGcYr oC2x/lkPUIKDg0VAReL7n3SQMJuAmcTzh1vA9okKJEt8vHMNqlxQ4uTMJywgtgjQHeuPPmAD sYUFQiTeti9hArGFgEbu37ccrJ5TQEdi24TzYHOYBcIkZt1+zQrxg5rE1XObmCHqtSR6z3Yy TWAUnoVkxSwkLRC2rcSFOdeh4vIS29/OYYawdSUu/J+CIr6AkW0VI3tuYmZOernRJkZg8B/c 8lt1B+OdcyKHGKU5WJTEecNdLwQICaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYKw7Kik4ffID kV98M/ZdF21XePhy9b3Je42vuzaE/D27rufdrdqWTaU/JLMcvfOXppVoXjQ8rB1iyPhS0IEj 78HZrw8uZdRvnpa19Iz/qeWuxjV6i+ME+cNffol043fxm6QoL1RSm30s4sL/xJt3srW8xI3X eE87/bEistMxWX2KlL+idWCCsRJLcUaioRZzUXEiAAIvcF5MAgAA Subject: Re: [webfinger] Working Group Last Call for draft-ietf-appsawg-webfinger-09 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, 01 Feb 2013 16:19:06 -0000 --------------030501070701000906020204 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit someone pointed out that the embedded link to WF, in the original announcement, takes you to the acct uri draft. sorry it was a cut and paste error! *here the right one:* http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-09 /Salvatore On 1/28/13 8:13 PM, Salvatore Loreto wrote: > Dear WG partecipants, > > > I would like to initiate a 2 weeks WG Last Call on > draft-ietf-appsawg-webfinger-09.txt ("WebFinger") > http://tools.ietf.org/id/draft-ietf-appsawg-webfinger-09.txt > > > Please send your reviews, as well as expression of support regarding > document readiness for IESG (or not) either to the *webfinger* mailing > list (webfinger@ietf.org), > or directly to the WG chairs (Murray Kucherawy and myself). > > Comments like "I've read the document and it is Ok to publish" or > "I've read the document and it has the following issues" > are useful and would be gratefully accepted by chairs. > > > The WG LC will end on Friday, February 8th. > > > Thank you, > Salvatore as an APPSAWG co-chair. > > > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger --------------030501070701000906020204 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
someone pointed out that
the embedded link to WF, in the original announcement, takes you to the acct uri draft.

sorry it was a cut and paste error!

*here the right one:*
http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-09

/Salvatore


On 1/28/13 8:13 PM, Salvatore Loreto wrote:
Dear WG partecipants,


I would like to initiate a 2 weeks WG Last Call on
draft-ietf-appsawg-webfinger-09.txt ("WebFinger")
http://tools.ietf.org/id/draft-ietf-appsawg-webfinger-09.txt


Please send your reviews, as well as expression of support regarding
document readiness for IESG (or not) either to the *webfinger* mailing list (webfinger@ietf.org),
or directly to the WG chairs (Murray Kucherawy and myself).

Comments like "I've read the document and it is Ok to publish" or
"I've read the document and it has the following issues"
are useful and would be gratefully accepted by chairs.


The WG LC will end on Friday, February 8th.


Thank you,
Salvatore as an APPSAWG co-chair. 




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

--------------030501070701000906020204-- From ve7jtb@ve7jtb.com Fri Feb 1 09:04:01 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 4E8AA21F8BBD for ; Fri, 1 Feb 2013 09:04:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.473 X-Spam-Level: X-Spam-Status: No, score=-3.473 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0N0liNBLOOd for ; Fri, 1 Feb 2013 09:04:00 -0800 (PST) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id DB9C821F85A4 for ; Fri, 1 Feb 2013 09:03:59 -0800 (PST) Received: by mail-qc0-f182.google.com with SMTP id k19so1828924qcs.41 for ; Fri, 01 Feb 2013 09:03:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=lq/EEMumg8gyh6ovjBqGmNnOR/o/cqtXfzrHzqJF/ig=; b=hZ+z0XIO2q39TDDqi8UkgMTWo7f1/QvzFOIRlMvw68Uocod6rf4+kTXiUjaOwiasVh KNE1Qh2/21/ujOfLWvurdqTgbB995H4Tfmz3RfbeWr3MaoEF51qltcjmyrL4bJtmYE9N P8JXnPu8MBpNd4u8lXHMrLvgXOQ9uuYbIZ+tlzpTQJV3tY+bAPObzNCV4hG0vd96/peU lgb8e7INTnX7849krbUOa05aDS8WXvLrrvNsyHtKItHrXqmVuupccC9fK6d0ZtjJxaTD xtxyWBIBd/DdXVrclq/rcAG/z2oy2p4oMGs7yDnMpJvnxfECJeFJbqA1YkB41F88RVxa LELQ== X-Received: by 10.229.180.72 with SMTP id bt8mr1986496qcb.32.1359738238971; Fri, 01 Feb 2013 09:03:58 -0800 (PST) Received: from [192.168.1.213] (190-20-61-57.baf.movistar.cl. [190.20.61.57]) by mx.google.com with ESMTPS id z17sm7160216qem.4.2013.02.01.09.03.54 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Feb 2013 09:03:56 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_A6B5EBED-D2D0-4B67-BBC7-B1219CC2AE2C" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: Date: Fri, 1 Feb 2013 14:03:54 -0300 Message-Id: <67F0E1A1-7533-47C4-8764-04FCF721F2F5@ve7jtb.com> References: <5106BFDC.2030706@ericsson.com> <976e3f7b-3173-4ceb-9b6e-7fb7d9128bfd@email.android.com> To: Melvin Carvalho X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQlK9HDEeNKVuIgHd9RHirV/cA0K5N50WJQ4q2Y3EDf+TrJWJkW0Ys/P6ODw4OhxYyeIBiRB Cc: Salvatore Loreto , "Paul E. Jones" , "Murray S. Kucherawy" , webfinger@ietf.org Subject: Re: [webfinger] Working Group Last Call for draft-ietf-appsawg-webfinger-09 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, 01 Feb 2013 17:04:01 -0000 --Apple-Mail=_A6B5EBED-D2D0-4B67-BBC7-B1219CC2AE2C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I have a hard time getting excited about the mime type. Having a specific mime type for JRD would be useful if we were going to = allow alternate JSON serializations. Lets not do that. Or if someone is going to let them register a = specific mime type for there JSON serialization. I think the spec is fine as is. I think it is ready for the IESG. John B. On 2013-02-01, at 12:30 PM, Melvin Carvalho = wrote: >=20 >=20 > On 1 February 2013 16:14, Paul E. Jones wrote: > Mervin, >=20 > What would be the reason? There are tons of applications that return = JSON, but they don't each have their own media type. We did that with = XML and have tons of media types, ask of which are just XML documents. >=20 > What is preferred by others? My preference is to leave it as defined. = Clients know what the response is. >=20 > Examining Eran's original post on JRD has it's own MIME type, which I = believe was always the intention: >=20 > Accept: application/xrd+json >=20 > = http://hueniverse.com/2010/05/jrd-the-other-resource-descriptor/#comment-8= 122 >=20 > In previous discussions, at least one person (I think it may have been = Tim Bray) has stated that this represents a best practice. >=20 > There are many JSON serializations out there, with JRD being = relatively bespoke. =20 >=20 > A MIME type would help the client understand what data it is getting = without close coupling to the URL that returned it, and also would aid = interoperability with other formats, in particular, many implementations = still use XRD, which uses (application/xrd+xml) >=20 >=20 > Paul >=20 > From: Melvin Carvalho > Sent: Tue Jan 29 13:40:38 EST 2013 > To: Salvatore Loreto > Cc: webfinger@ietf.org, "Murray S. Kucherawy" > Subject: Re: [webfinger] Working Group Last Call for = draft-ietf-appsawg-webfinger-09 >=20 >=20 >=20 > On 28 January 2013 19:13, Salvatore Loreto = wrote: > Dear WG partecipants,=20 >=20 >=20 > I would like to initiate a 2 weeks WG Last Call on=20 > draft-ietf-appsawg-webfinger-09.txt ("WebFinger")=20 > http://tools.ietf.org/id/draft-ietf-appsawg-webfinger-09.txt >=20 >=20 > Please send your reviews, as well as expression of support regarding=20= > document readiness for IESG (or not) either to the *webfinger* mailing = list (webfinger@ietf.org),=20 > or directly to the WG chairs (Murray Kucherawy and myself).=20 >=20 > Comments like "I've read the document and it is Ok to publish" or=20 > "I've read the document and it has the following issues" > are useful and would be gratefully accepted by chairs.=20 >=20 > I have read the document and I think the JRD should have it's own MIME = type, which the client SHOULD send with the HTTP(S) GET. =20 > =20 >=20 >=20 > The WG LC will end on Friday, February 8th.=20 >=20 >=20 > Thank you,=20 > Salvatore as an APPSAWG co-chair.=20 >=20 >=20 >=20 > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger >=20 >=20 >=20 >=20 > webfinger mailing list > webfinger@ietf.org >=20 > https://www.ietf.org/mailman/listinfo/webfinger >=20 > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger --Apple-Mail=_A6B5EBED-D2D0-4B67-BBC7-B1219CC2AE2C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 I = have a hard time getting excited about the mime = type.

Having a specific mime type for JRD would be = useful if we were going to allow alternate JSON = serializations.
Lets not do that.  Or if someone is going = to let them register a specific mime type for there JSON = serialization.

I think the spec is fine as is. =  I think it is ready for the IESG.

John = B.



On 2013-02-01, = at 12:30 PM, Melvin Carvalho <melvincarvalho@gmail.com> = wrote:



On 1 February 2013 = 16:14, Paul E. Jones <paulej@packetizer.com> = wrote:
Mervin,

What would be the reason? There are tons of applications that return = JSON, but they don't each have their own media type. We did that with = XML and have tons of media types, ask of which are just XML = documents.

What is preferred by others? My preference is to leave it as defined. = Clients know what the response = is.

Examining Eran's original post on JRD = has it's own MIME type, which I believe was always the intention:

Accept: application/xrd+json

http://hueniverse.com/2010/05/jrd-the-other-resource-descript= or/#comment-8122

In previous discussions, at least one person = (I think it may have been Tim Bray) has stated that this represents a = best practice.

There are many JSON serializations out there, with JRD being = relatively bespoke. 

A MIME type would help the client = understand what data it is getting without close coupling to the URL = that returned it, and also would aid interoperability with other = formats, in particular, many implementations still use XRD, which uses = (application/xrd+xml)


Paul

From: Melvin Carvalho <melvincarvalho@gmail.com>
Sent: Tue Jan 29 13:40:38 EST 2013
To: Salvatore Loreto <salvatore.loreto@ericsson.com>
Cc: webfinger@ietf.org, "Murray S. Kucherawy" <superuser@gmail.com>
Subject: Re: [webfinger] Working Group Last Call for = draft-ietf-appsawg-webfinger-09



On 28 January 2013 19:13, Salvatore = Loreto <salvatore.loreto@ericsson.com> = wrote:
=20 =20 =20
Dear WG partecipants,


I would like to initiate a 2 weeks WG Last Call on
draft-ietf-appsawg-webfinger-09.txt ("WebFinger")
http://tools.ietf.org/id/draft-ietf-appsawg-webfinger-09= .txt


Please send your reviews, as well as expression of support regarding
document readiness for IESG (or not) either to the = *webfinger* mailing list (webfinger@ietf.org),
or directly to the WG chairs (Murray Kucherawy and myself).

Comments like "I've read the document and it is Ok to publish" or =
"I've read the document and it has the following issues"
are useful and would be gratefully accepted by chairs.

I have read the document and I think = the JRD should have it's own MIME type, which the client SHOULD send = with the HTTP(S) GET. 
 


The WG LC will end on Friday, February 8th.


Thank you,
Salvatore as an APPSAWG co-chair.



_______________________________________________
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
<=
/pre>

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

= = --Apple-Mail=_A6B5EBED-D2D0-4B67-BBC7-B1219CC2AE2C-- From bradfitz@google.com Fri Feb 1 09:12: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 792BA21F8EC0 for ; Fri, 1 Feb 2013 09:12:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.477 X-Spam-Level: X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qm2xIuopXUsH for ; Fri, 1 Feb 2013 09:12:50 -0800 (PST) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by ietfa.amsl.com (Postfix) with ESMTP id 7DACC21F8ED4 for ; Fri, 1 Feb 2013 09:12:49 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id hm14so839772wib.3 for ; Fri, 01 Feb 2013 09:12:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=xc2Th9XPXcE/yCg1BkooR3afmHXgKDudfH6i6n999IU=; b=VOsr9ZjqWy41XQds9zQuSKzcJMex6zo81iHFLNaRbhms4HAIxDt+izcI1QfnaVyBfq dsnunCTwgO6THsPshm62fXI9peZ+iepG9P5CsRgrhnyTBUUpC8e4DxIWp5pPvfMVvf3H qKn6cWYkcETTmMMLyH7hGoKyc9yAbDkqSh6lPzJm8hJCUQ95mzNvZDeOTZL09UJvviag 4CiP/DBIaUe8ZI/HKghlL0wMff+Lfyk7Hs/rEKpXCrW12Fbg2P6yvH+ajj8FfpcqGGGm 7SYuD9kW5qL2AnyqQ8Nd/OEvqlOLDfNujXhwgzyJ0ri16PhQikSYk//QifU00eLaJ+sW Fbiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=xc2Th9XPXcE/yCg1BkooR3afmHXgKDudfH6i6n999IU=; b=pxIxY071yL95RYD+Q09Hulv0276jnIWk9bLMFdonPEdcaRIJjH43Z5cx/gtgHV2Rx2 acveHeEt02Kc3kBUZ2mxNsTd4bqDHgRvAhH1jASpnlkATWQx0TZ5S63YHlo2ToWcBMiE 2dTz9B+uspqWL7rDLp4VYkCIZgUNSfUjnenHO98CVnkneg7UGLciRyypS6cpdhgcf41a cyjB8vTPuIrN8MopNrD7Qze62R36AXWjveUfxqsXnIbOkiTIrYv4fDXLtRA1oVFDBukr e03p1ivhGCtd1/ZtDd+aXJ1JeAgGHylhSemq5OZgakLbCZY3Wnqh1QHdeTA6pv/khxI7 REEQ== MIME-Version: 1.0 X-Received: by 10.180.93.100 with SMTP id ct4mr3826044wib.32.1359738766215; Fri, 01 Feb 2013 09:12:46 -0800 (PST) Received: by 10.194.46.97 with HTTP; Fri, 1 Feb 2013 09:12:46 -0800 (PST) In-Reply-To: <5106BFDC.2030706@ericsson.com> References: <5106BFDC.2030706@ericsson.com> Date: Fri, 1 Feb 2013 09:12:46 -0800 Message-ID: From: Brad Fitzpatrick To: Salvatore Loreto Content-Type: multipart/alternative; boundary=f46d043d677325ca4b04d4acdad9 X-Gm-Message-State: ALoCoQlcmoFz78+kvM/Zri55zg7ycKDRRhvp37ojrka7TSzzVeGWXD5ASl7iRgUrXQPxX6xiMpRkVr/KhRt26DolHli4Y/mV2EC9MTHLsoQYBmCGCwrv4/h8WqJrDPdEHduneUoyYIrGNJMKfC4BP+7jD//A8+3KWqLmSC1afIF7pDPvNK59l51G/28uRgzsnIRoJ5mpm4I5 Cc: "webfinger@ietf.org" , "Murray S. Kucherawy" Subject: Re: [webfinger] Working Group Last Call for draft-ietf-appsawg-webfinger-09 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, 01 Feb 2013 17:12:51 -0000 --f46d043d677325ca4b04d4acdad9 Content-Type: text/plain; charset=UTF-8 +1 Looks good to me. On Mon, Jan 28, 2013 at 10:13 AM, Salvatore Loreto < salvatore.loreto@ericsson.com> wrote: > Dear WG partecipants, > > > I would like to initiate a 2 weeks WG Last Call on > draft-ietf-appsawg-webfinger-09.txt ("WebFinger") > http://tools.ietf.org/id/draft-ietf-appsawg-webfinger-09.txt > > > Please send your reviews, as well as expression of support regarding > document readiness for IESG (or not) either to the **webfinger** mailing > list (webfinger@ietf.org), > or directly to the WG chairs (Murray Kucherawy and myself). > > Comments like "I've read the document and it is Ok to publish" or > "I've read the document and it has the following issues" > are useful and would be gratefully accepted by chairs. > > > The WG LC will end on Friday, February 8th. > > > Thank you, > Salvatore as an APPSAWG co-chair. > > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > > --f46d043d677325ca4b04d4acdad9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

Looks good to me.



On Mon, Jan 28, 2013 at 10:13 AM, Salvatore Loreto <sal= vatore.loreto@ericsson.com> wrote:
=20 =20 =20
Dear WG partecipants,


I would like to initiate a 2 weeks WG Last Call on
draft-ietf-appsawg-webfinger-09.txt ("WebFinger")
http://tools.ietf.org/id/draft-ietf-appsawg-webfinger-09= .txt


Please send your reviews, as well as expression of support regarding
document readiness for IESG (or not) either to the *web= finger* mailing list (webfinger@ietf= .org),
or directly to the WG chairs (Murray Kucherawy and myself).

Comments like "I've read the document and it is Ok to publish&= quot; or
"I've read the document and it has the following issues"<= br> are useful and would be gratefully accepted by chairs.


The WG LC will end on Friday, February 8th.


Thank you,
Salvatore as an APPSAWG co-chair.



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


--f46d043d677325ca4b04d4acdad9-- From sm@resistor.net Thu Jan 31 16:25:02 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 1E0AE21F8459 for ; Thu, 31 Jan 2013 16:25:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sY2DNkWCi-fR for ; Thu, 31 Jan 2013 16:25:01 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5882D21F8A42 for ; Thu, 31 Jan 2013 16:25:01 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r110OrBW029060; Thu, 31 Jan 2013 16:24:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1359678298; bh=nQEob2lETRxCm6BWd15swver62+4CdQ94K6OgKZTV+c=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Kx4sPuo9ID+s0fEIcpO4cG9myNwTwNdItnBK0hzzZFTFQdqKrQD7ebssqcrHS0dK0 2hw5BX8y3wYspNgEGoaFyHufToxMHrBz0UJdXUfINA5jeHQYU6g2tIu1uyIHTBLaF4 fRG6vFlB8bEVc2gddFvfNVXKzaPgzThezcg+BoQY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1359678298; i=@resistor.net; bh=nQEob2lETRxCm6BWd15swver62+4CdQ94K6OgKZTV+c=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=LdmUtyd1+Q3fmdVtjx7Iy7b98mTIr+W19NsgkztquOMG2ZXLbrl3v86L6gEpCBbGn DZ+7jgKwXOyfJ3gZgXdL1dXPNnObMSZNjGdTSOkDKKPESPtq9nZWlrkBFPd/5K6HT2 LhNSFYyO9/DiSsNmtGKeD/TR3BNTSHD1ULYWJdr4= Message-Id: <6.2.5.6.2.20130131151432.0aaf2b68@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 31 Jan 2013 16:15:19 -0800 To: Salvatore Loreto From: SM In-Reply-To: <5106C090.8080403@ericsson.com> References: <5106BFDC.2030706@ericsson.com> <5106C090.8080403@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailman-Approved-At: Fri, 01 Feb 2013 11:30:43 -0800 Cc: webfinger@ietf.org Subject: Re: [webfinger] [apps-discuss] Working Group Last Call for draft-ietf-appsawg-webfinger-09 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, 01 Feb 2013 00:25:02 -0000 At 10:16 28-01-2013, Salvatore Loreto wrote: >the 2 weeks WGLC on draft-ietf-appsawg-webfinger is started. >Please see the mail below and note that the right venue for discussion is >the *webfinger* mailing list These are quick comments. In Section 3.1: "rel" : "http://webfinger.net/rel/avatar", "type" : "image/jpeg", "href" : "http://www.example.com/~bob/bob.jpg" }, { "rel" : "http://webfinger.net/rel/profile-page", "href" : "http://www.example.com/~bob/" In Section 4.3: In this example, the client requests the link relations of type "http://webfinger.net/rel/profile-page" and "vcard". The server then "links" : [ { "rel" : "http://webfinger.net/rel/profile-page", "href" : "http://www.example.com/~bob/" In Section 4.4.4: "properties" : { "http://webfinger.net/ns/name" : "Bob Smith" } I suggest using RFC 2606 domain names. In the references section: RFC 4288 should be replaced by RFC 6838. In Section 3.3: "WebFinger could be used to auto-provision an email client with basic configuration data." RFC 6186 describes how SRV records can be used to locate email services. It's confusing if there is another Proposed Standard specifying another way to do the same thing. In Section 4.3: "Support for the "rel" parameter is OPTIONAL, but RECOMMENDED on the server." Either the above is recommended or it is optional. Having both does not make sense (see RFC 2119). In Section 4.4.5.1: "The value of the "rel" member MUST contain exactly one URI string or registered relation type and MUST NOT contain a space-separated list of URIs or registered relation types." The MUST condition already implies the "MUST NOT" condition. What's a URI string? In Section 7: "An MX record points to the mail server to which mail for the domain should be delivered. It does not matter to the sending mail server whether those MX records point to a server in the destination domain or a different domain." It may be easier to reference RFC 5321 instead of explaining how SMTP works. In Section 8: "Clients MUST verify that the certificate used on an HTTPS connection is valid and accept a response only if the certificate is valid." Maybe the working group would like to reference RFC 6125. "WebFinger server MUST NOT be used to provide any personal information to any party unless explicitly or implicitly authorized by the person whose information is being shared." I suggest using "consent" instead of "authorized". "Implicit authorization can be determined by the user's voluntary utilization of a service as defined by that service's relevant terms of use or published privacy policy." I don't think it is up to this document to get into such advice. People generally do not read the terms of service or privacy policy. The guidance comes out as how to get around the "MUST NOT". Regards, -sm From barryleiba.mailing.lists@gmail.com Sat Feb 2 08:21: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 18B8821F867A for ; Sat, 2 Feb 2013 08:21:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.012 X-Spam-Level: X-Spam-Status: No, score=-103.012 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y55JXvp0zzV5 for ; Sat, 2 Feb 2013 08:20:59 -0800 (PST) Received: from mail-vc0-f180.google.com (mail-vc0-f180.google.com [209.85.220.180]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC5421F851C for ; Sat, 2 Feb 2013 08:20:59 -0800 (PST) Received: by mail-vc0-f180.google.com with SMTP id fo13so3036370vcb.39 for ; Sat, 02 Feb 2013 08:20:58 -0800 (PST) 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=nVFU7HiJUrBChCSRz8SovUzQIyH0BZZaPDMREVZxp4o=; b=SANvq0NmPb27y61TPB6+Lj4S1H0MLmknhRLhLhfqLqf/5HxUFS5BzQIJKftnJTud5S jm4k8FOcVr73tSLGGit7EtU9vyEjoCPAkkzXKtdEqifIjJAda5PaMnt0YQF8OuPKRwLY /fhnNRbDqIbX3FFWL9Y5eze3FkSuCsxbI/EEAbtZbbfZp+/KBo/p+KA7Uhz+rLqI2h52 /DPwawyHOtIJ3OoUj0NWRhxEQWLyn1bdL1sqw5qmub+n8++222wZwa9URVN5HVjkRiHV c1ZucMV4Rxx6hJAl5ib4FCCOJ+VAjE0BvIiVZgm0Sie8b7jWPVWX+cr1wjrJeOARyOy4 6lmQ== MIME-Version: 1.0 X-Received: by 10.220.151.5 with SMTP id a5mr14883016vcw.22.1359822058722; Sat, 02 Feb 2013 08:20:58 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.59.3.41 with HTTP; Sat, 2 Feb 2013 08:20:58 -0800 (PST) In-Reply-To: <976e3f7b-3173-4ceb-9b6e-7fb7d9128bfd@email.android.com> References: <5106BFDC.2030706@ericsson.com> <976e3f7b-3173-4ceb-9b6e-7fb7d9128bfd@email.android.com> Date: Sat, 2 Feb 2013 11:20:58 -0500 X-Google-Sender-Auth: Qmrl-AIiheS0FMm4j1B5Q5Gxv10 Message-ID: From: Barry Leiba To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=f46d043be016c494f904d4c03e3c Cc: Salvatore Loreto , "webfinger@ietf.org" , "Murray S. Kucherawy" Subject: Re: [webfinger] Working Group Last Call for draft-ietf-appsawg-webfinger-09 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, 02 Feb 2013 16:21:00 -0000 --f46d043be016c494f904d4c03e3c Content-Type: text/plain; charset=ISO-8859-1 > What would be the reason? There are tons of applications that return JSON, but they > don't each have their own media type. We did that with XML and have tons of media > types, ask of which are just XML documents. The general reason is that if someone sends you an email message, for example, with an application/xml attachment, how is your mail program to know which program to run in order to handle it? It's not like we have a generic XML handler that parses XML, figures out what program it's for, then invokes it with the parsed XML. The distinct media types help sort this out. You can argue that you have context from elsewhere that makes this work without media types, but that won't always be the case with many JSON things. Barry --f46d043be016c494f904d4c03e3c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >=A0What would be the reason? There are tons of applications that ret= urn JSON, but they
> don't each have their own = media type. We did that with XML and have tons of media
>=A0types, ask of which are just XML documents.

The general reason is that if someone sends you= an email message, for example, with an application/xml attachment, how is = your mail program to know which program to run in order to handle it? =A0It= 's not like we have a generic XML handler that parses XML, figures out = what program it's for, then invokes it with the parsed XML. =A0The dist= inct media types help sort this out.

You can argue that you have context= from elsewhere that makes this work without media types, but that won'= t always be the case with many JSON things.

Barry --f46d043be016c494f904d4c03e3c-- From stpeter@stpeter.im Mon Feb 4 19:27:02 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 4929321F898A for ; Mon, 4 Feb 2013 19:27:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8fx4elEjCY4 for ; Mon, 4 Feb 2013 19:27:01 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 543FB21F88FB for ; Mon, 4 Feb 2013 19:27:00 -0800 (PST) Received: from [192.168.1.5] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B56F640C1F; Mon, 4 Feb 2013 20:33:37 -0700 (MST) Message-ID: <51103D30.2010701@stpeter.im> Date: Mon, 04 Feb 2013 15:58:56 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Brad Fitzpatrick References: <5106BFDC.2030706@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Salvatore Loreto , "webfinger@ietf.org" , "Murray S. Kucherawy" Subject: Re: [webfinger] Working Group Last Call for draft-ietf-appsawg-webfinger-09 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, 05 Feb 2013 03:27:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/1/13 10:12 AM, Brad Fitzpatrick wrote: > +1 > > Looks good to me. Here too. I sent a bunch of editorial feedback to the authors, but I see no substantive technical problems here. Kudos to the authors for their work on the spec! Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlEQPTAACgkQNL8k5A2w/vwi/ACgnjcwR3jTFcbfGebjtiXduydT /gEAoK0SpA17y08zxtJB8vNidYqM9Kds =RV/l -----END PGP SIGNATURE----- From gsalguei@cisco.com Mon Feb 4 20:08: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 59B3621F8820 for ; Mon, 4 Feb 2013 20:08:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.47 X-Spam-Level: X-Spam-Status: No, score=-10.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P--lAR5HtU4Z for ; Mon, 4 Feb 2013 20:08:24 -0800 (PST) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 97B8721F85A1 for ; Mon, 4 Feb 2013 20:08:24 -0800 (PST) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r1548OJq029284 for ; Mon, 4 Feb 2013 23:08:24 -0500 (EST) Received: from rtp-gsalguei-8918.cisco.com (rtp-gsalguei-8918.cisco.com [10.116.132.57]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r1548No4022793; Mon, 4 Feb 2013 23:08:23 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Gonzalo Salgueiro In-Reply-To: <51103D30.2010701@stpeter.im> Date: Mon, 4 Feb 2013 23:08:23 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <548BEEAE-E92F-461F-B06F-ABB40EB9F22C@cisco.com> References: <5106BFDC.2030706@ericsson.com> <51103D30.2010701@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1499) Cc: Salvatore Loreto , Brad Fitzpatrick , Murray Kucherawy , webfinger@ietf.org Subject: Re: [webfinger] Working Group Last Call for draft-ietf-appsawg-webfinger-09 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, 05 Feb 2013 04:08:25 -0000 On Feb 4, 2013, at 5:58 PM, Peter Saint-Andre = wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 2/1/13 10:12 AM, Brad Fitzpatrick wrote: >> +1 >>=20 >> Looks good to me. >=20 > Here too. I sent a bunch of editorial feedback to the authors, but I > see no substantive technical problems here. Kudos to the authors for > their work on the spec! Thanks for the extremely detailed review. Upon quick inspection the = suggested edits seem perfectly reasonable. The post WGLC version will = include these. Gonzalo >=20 > Peter >=20 > - --=20 > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >=20 > iEYEARECAAYFAlEQPTAACgkQNL8k5A2w/vwi/ACgnjcwR3jTFcbfGebjtiXduydT > /gEAoK0SpA17y08zxtJB8vNidYqM9Kds > =3DRV/l > -----END PGP SIGNATURE----- > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger >=20 From tbray@textuality.com Mon Feb 4 20:49:13 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 E88E321F873E for ; Mon, 4 Feb 2013 20:49:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.177 X-Spam-Level: X-Spam-Status: No, score=-5.177 tagged_above=-999 required=5 tests=[AWL=-2.201, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zSQZDuAZuuGC for ; Mon, 4 Feb 2013 20:49:12 -0800 (PST) Received: from mail-oa0-f49.google.com (mail-oa0-f49.google.com [209.85.219.49]) by ietfa.amsl.com (Postfix) with ESMTP id A15DC21F871E for ; Mon, 4 Feb 2013 20:49:11 -0800 (PST) Received: by mail-oa0-f49.google.com with SMTP id j6so7331712oag.22 for ; Mon, 04 Feb 2013 20:49:11 -0800 (PST) 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=J50o0TG8DjXM5NUaMdwdVzil1g6TM3D5yV09Z7ryQCQ=; b=b3uQJ7lgB2jMP8u/pmLFyXJdNeWhK8rSU6w7bZVvSRAVYvUJLV5hRyZcPG8rD9YgZE 3YjLYQ6puEY56qY9yeWMFm+gJn1HIOtW/pfAQNw/JkzA/JXovvDuhPZmCtwAxS6jCPL9 GxWFsvyuQ71UUoSGaYX/rztRe+DwkOkctC562j+oJyb7pBqdJsAuamAtuaVF1DvYXH1R cNnR0r+jq/PySudoVq4SBA1zdok83z86la/z4MTtSOohZ8h9uhulDMUIEgCqgeySAYeU oaz2K2KGyPA0kQuP+eJY0It60xd3v/I+ac+oMYG+Ge37DAYoFC6HqF4YZd36/jH1SEY/ 2OgQ== MIME-Version: 1.0 X-Received: by 10.60.32.193 with SMTP id l1mr17890998oei.114.1360039750996; Mon, 04 Feb 2013 20:49:10 -0800 (PST) Received: by 10.76.28.66 with HTTP; Mon, 4 Feb 2013 20:49:10 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: <548BEEAE-E92F-461F-B06F-ABB40EB9F22C@cisco.com> References: <5106BFDC.2030706@ericsson.com> <51103D30.2010701@stpeter.im> <548BEEAE-E92F-461F-B06F-ABB40EB9F22C@cisco.com> Date: Mon, 4 Feb 2013 20:49:10 -0800 Message-ID: From: Tim Bray To: Gonzalo Salgueiro Content-Type: multipart/alternative; boundary=e89a8fb1f6ca3d14c204d4f2eeaa X-Gm-Message-State: ALoCoQn7k+GoMs89thHG/k5uFL4eC/ovox0DzZkhtW6eltYF3natzZC4Yyez1XIECvTmVylQ6mew Cc: Salvatore Loreto , Brad Fitzpatrick , Murray Kucherawy , Peter Saint-Andre , "webfinger@ietf.org" Subject: Re: [webfinger] Working Group Last Call for draft-ietf-appsawg-webfinger-09 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, 05 Feb 2013 04:49:13 -0000 --e89a8fb1f6ca3d14c204d4f2eeaa Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable One editorial issue, which has no effect on the actual normative effect. 4.2 says =93A WebFinger client issues a query to the well-known [3] resourc= e /.well-known/webfinger.=94 Um, not really; that isn=92t a resource, that=92s part of a URI. Language should be along the lines of =93It issues a query to the resource identifie= d by the URI whose path component begins with =93/.well-known/webfinger?=94 a= nd whose query component MUST include include the "resource" parameter exactly....=94 [proceed as before]. I=92d say I hate to be pedantic, but evidence would be against me. In my defense, publications of the IETF should be careful of their nomenclature about important things like resources and URIs. -T On Mon, Feb 4, 2013 at 8:08 PM, Gonzalo Salgueiro wrote= : > > On Feb 4, 2013, at 5:58 PM, Peter Saint-Andre wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On 2/1/13 10:12 AM, Brad Fitzpatrick wrote: > >> +1 > >> > >> Looks good to me. > > > > Here too. I sent a bunch of editorial feedback to the authors, but I > > see no substantive technical problems here. Kudos to the authors for > > their work on the spec! > > Thanks for the extremely detailed review. Upon quick inspection the > suggested edits seem perfectly reasonable. The post WGLC version will > include these. > > Gonzalo > > > > > Peter > > > > - -- > > Peter Saint-Andre > > https://stpeter.im/ > > > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > > > iEYEARECAAYFAlEQPTAACgkQNL8k5A2w/vwi/ACgnjcwR3jTFcbfGebjtiXduydT > > /gEAoK0SpA17y08zxtJB8vNidYqM9Kds > > =3DRV/l > > -----END PGP SIGNATURE----- > > _______________________________________________ > > 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 > --e89a8fb1f6ca3d14c204d4f2eeaa Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
One editorial issue, which has no effect on the actua= l normative effect.=A0 4.2 says =93A WebFinger client issues a query to the= well-known [3] resource
=A0=A0 /.well-known/webfinger.=94=A0

Um= , not really; that isn=92t a resource, that=92s part of a URI.=A0 Language = should be along the lines of =93It issues a query to the resource identifie= d by the URI whose path component begins with =93/.well-known/webfinger?=94= and whose query component MUST include include the "resource" pa= rameter exactly....=94 [proceed as before].

I=92d say I hate to be pedantic, but evidence would be against me= .=A0 In my defense, publications of the IETF should be careful of their nom= enclature about important things like resources and URIs.=A0 -T


On Mon, Feb 4, 2013 at 8:08 PM, Gonzalo = Salgueiro <gsalguei@cisco.com> wrote:

On Feb 4, 2013, at 5:58 PM, Peter Saint-Andre <stpeter@stpeter.im> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 2/1/13 10:12 AM, Brad Fitzpatrick wrote:
>> +1
>>
>> Looks good to me.
>
> Here too. I sent a bunch of editorial feedback to the authors, but I > see no substantive technical problems here. Kudos to the authors for > their work on the spec!

Thanks for the extremely detailed review. =A0Upon quick inspection th= e suggested edits seem perfectly reasonable. =A0The post WGLC version will = include these.

Gonzalo

>
> Peter
>
> - --
> Peter Saint-Andre
> https://stpeter.im/<= /a>
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlEQPTAACgkQNL8k5A2w/vwi/ACgnjcwR3jTFcbfGebjtiXduydT
> /gEAoK0SpA17y08zxtJB8vNidYqM9Kds
> =3DRV/l
> -----END PGP SIGNATURE-----
> _______________________________________________
> 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

--e89a8fb1f6ca3d14c204d4f2eeaa-- From gsalguei@cisco.com Mon Feb 4 21:00:21 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 5373221F8964 for ; Mon, 4 Feb 2013 21:00:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.486 X-Spam-Level: X-Spam-Status: No, score=-10.486 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9cI0oX2Qsl4 for ; Mon, 4 Feb 2013 21:00:20 -0800 (PST) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA9421F88E1 for ; Mon, 4 Feb 2013 21:00:20 -0800 (PST) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r1550Juu004690 for ; Tue, 5 Feb 2013 00:00:19 -0500 (EST) Received: from rtp-gsalguei-8918.cisco.com (rtp-gsalguei-8918.cisco.com [10.116.132.57]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r1550IVT014309; Tue, 5 Feb 2013 00:00:19 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Gonzalo Salgueiro In-Reply-To: Date: Tue, 5 Feb 2013 00:00:18 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <488AD1BB-716F-459E-9FCE-E1D80488D4F3@cisco.com> References: <5106BFDC.2030706@ericsson.com> <51103D30.2010701@stpeter.im> <548BEEAE-E92F-461F-B06F-ABB40EB9F22C@cisco.com> To: Tim Bray X-Mailer: Apple Mail (2.1499) Cc: Salvatore Loreto , Brad Fitzpatrick , Murray Kucherawy , Peter Saint-Andre , webfinger@ietf.org Subject: Re: [webfinger] Working Group Last Call for draft-ietf-appsawg-webfinger-09 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, 05 Feb 2013 05:00:21 -0000 Pedantic is good in this case. A subtle difference, but valid IMO. I = think we can improve the wording but I understand the spirit of your = comment. I'll let Paul (as principal editor) comment on specific text. Thanks, Gonzalo On Feb 4, 2013, at 11:49 PM, Tim Bray wrote: > One editorial issue, which has no effect on the actual normative = effect. 4.2 says =93A WebFinger client issues a query to the well-known = [3] resource > /.well-known/webfinger.=94 =20 >=20 > Um, not really; that isn=92t a resource, that=92s part of a URI. = Language should be along the lines of =93It issues a query to the = resource identified by the URI whose path component begins with = =93/.well-known/webfinger?=94 and whose query component MUST include = include the "resource" parameter exactly....=94 [proceed as before]. >=20 > I=92d say I hate to be pedantic, but evidence would be against me. In = my defense, publications of the IETF should be careful of their = nomenclature about important things like resources and URIs. -T >=20 >=20 > On Mon, Feb 4, 2013 at 8:08 PM, Gonzalo Salgueiro = wrote: >=20 > On Feb 4, 2013, at 5:58 PM, Peter Saint-Andre = wrote: >=20 > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On 2/1/13 10:12 AM, Brad Fitzpatrick wrote: > >> +1 > >> > >> Looks good to me. > > > > Here too. I sent a bunch of editorial feedback to the authors, but I > > see no substantive technical problems here. Kudos to the authors for > > their work on the spec! >=20 > Thanks for the extremely detailed review. Upon quick inspection the = suggested edits seem perfectly reasonable. The post WGLC version will = include these. >=20 > Gonzalo >=20 > > > > Peter > > > > - -- > > Peter Saint-Andre > > https://stpeter.im/ > > > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > > > iEYEARECAAYFAlEQPTAACgkQNL8k5A2w/vwi/ACgnjcwR3jTFcbfGebjtiXduydT > > /gEAoK0SpA17y08zxtJB8vNidYqM9Kds > > =3DRV/l > > -----END PGP SIGNATURE----- > > _______________________________________________ > > webfinger mailing list > > webfinger@ietf.org > > https://www.ietf.org/mailman/listinfo/webfinger > > >=20 > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger >=20 From gsalguei@cisco.com Mon Feb 4 23:03: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 D47BA21F854F for ; Mon, 4 Feb 2013 23:03:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAhIIDAwG2Fc for ; Mon, 4 Feb 2013 23:03:00 -0800 (PST) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id EF76B21F8951 for ; Mon, 4 Feb 2013 23:02:59 -0800 (PST) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r1572xb0015646 for ; Tue, 5 Feb 2013 02:02:59 -0500 (EST) Received: from rtp-gsalguei-8918.cisco.com (rtp-gsalguei-8918.cisco.com [10.116.132.57]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r1572rnL014794 for ; Tue, 5 Feb 2013 02:02:53 -0500 (EST) From: Gonzalo Salgueiro Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 5 Feb 2013 02:02:52 -0500 References: To: "webfinger@ietf.org" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [webfinger] Fwd: [apps-discuss] WGLC feedback on webfinger-09 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, 05 Feb 2013 07:03:00 -0000 Posting to Webfinger list for visibility. --G Begin forwarded message: > From: Mark Nottingham > Subject: [apps-discuss] WGLC feedback on webfinger-09 > Date: February 5, 2013 1:58:02 AM EST > To: "apps-discuss@ietf.org Discuss" >=20 > Had a quick read of this draft. Overall this looks pretty good; the = points I raise are fairly minor. >=20 > 1) The introduction seems to be missing a vital bit of information: = that the Whole Point -- the Big Trick -- that WebFinger performs is = (AIUI) that you can use an identifier that might not be usable as a = locator (e.g., a mailto: uri, an acct: uri) as a locator. In that sense, = it's really just a more real-world-usable URN lookup facility*. >=20 > This is really important to include in the abstract as well as the = introduction, because without it, WF just seems like a silly indirection = mechanism on top of HTTP. >=20 > 2) The examples use unregistered link relations types = ; = specifically, "blog" and "vcard". Naughty. >=20 > 3) The text in section 4.1 isn't precise enough; consider the "=3D" = and "&" characters, which are NOT required to be percent-encoded by = RFC3986 section 2.1. Also, the things that section is defining are not = "URI parameters" (which is things after a semicolon in a path segment); = it's a query string format. Really, what you want to do is either: a) = reference or re-define = , or b) define a subset of it that's = simple yet precise. >=20 > 4) Section 4.2 would be a lot clearer if you just said that the = well-known location is ONLY defined for the HTTPS URI scheme. >=20 > 5) Why not define a media type for JRD? You can instruct clients to = also accept application/json if you're worried about bad server = configurations. >=20 > 6) What's the motivation for expires, given that HTTP caching = information is already available? Have you considered the interaction = between them? >=20 > 7) Section 4.4.5 "user's preferred link relation." --> "user's = preferred link relation type." (and likely elsewhere). >=20 > 8) RFC5988 defines the "target IRI" as what's at the end of the link; = here, "linked resource" is used (e.g., 4.4.5.[2,3]). Suggest "target = resource" as a way to tie them together conceptually. >=20 > 9) Similarly, an important concept in 5988 is the "context" of the = link; suggest saying that the context of all of these links is the = subject(s). >=20 > 10) What if a target resource supports multiple media types for the = same relation? Suggest allowing multiple values in "type." >=20 > 11) 4.5 says "WebFinger requests can include a parameter = specifying..." What kind of parameter? Tie it back to what happens in = 4.1. >=20 > 12) 4.5 says "WebFinger is agnostic regarding the scheme of such a = URI..." I think you mean "neutral", unless the protocol really = believes that the scheme is unknowable. >=20 > Lucky 13) "For resources associated with a user account at a host..." = --> "To perform a webfinger lookup on an account specific to the host = being queried..." >=20 > 14) In section 7 (and likely elsewhere), you should use the full URL, = not just the path /.well-known/webfinger, to make it clear that this is = just over HTTPS. >=20 > Cheers, >=20 >=20 > * I'm not INTENTIONALLY trolling here; if it starts a fight, it's not = my fault. >=20 > -- > Mark Nottingham http://www.mnot.net/ >=20 >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 From mnot@mnot.net Tue Feb 5 01:24: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 23DC921F87B2 for ; Tue, 5 Feb 2013 01:24:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.743 X-Spam-Level: X-Spam-Status: No, score=-105.743 tagged_above=-999 required=5 tests=[AWL=-3.144, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQeRXvXqXErr for ; Tue, 5 Feb 2013 01:24:48 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 6810A21F8753 for ; Tue, 5 Feb 2013 01:24:47 -0800 (PST) Received: from [192.168.1.80] (unknown [118.209.138.158]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id CDDAC22E1F4 for ; Tue, 5 Feb 2013 04:24:40 -0500 (EST) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 5 Feb 2013 20:24:54 +1100 References: To: webfinger@ietf.org Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-Mailman-Approved-At: Tue, 05 Feb 2013 01:29:54 -0800 Subject: [webfinger] Fwd: WGLC feedback on webfinger-09 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, 05 Feb 2013 09:24:49 -0000 Forwarding upon request. Begin forwarded message: > From: Mark Nottingham > Subject: WGLC feedback on webfinger-09 > Date: 5 February 2013 5:58:02 PM AEDT > To: "apps-discuss@ietf.org Discuss" >=20 > Had a quick read of this draft. Overall this looks pretty good; the = points I raise are fairly minor. >=20 > 1) The introduction seems to be missing a vital bit of information: = that the Whole Point -- the Big Trick -- that WebFinger performs is = (AIUI) that you can use an identifier that might not be usable as a = locator (e.g., a mailto: uri, an acct: uri) as a locator. In that sense, = it's really just a more real-world-usable URN lookup facility*. >=20 > This is really important to include in the abstract as well as the = introduction, because without it, WF just seems like a silly indirection = mechanism on top of HTTP. >=20 > 2) The examples use unregistered link relations types = ; = specifically, "blog" and "vcard". Naughty. >=20 > 3) The text in section 4.1 isn't precise enough; consider the "=3D" = and "&" characters, which are NOT required to be percent-encoded by = RFC3986 section 2.1. Also, the things that section is defining are not = "URI parameters" (which is things after a semicolon in a path segment); = it's a query string format. Really, what you want to do is either: a) = reference or re-define = , or b) define a subset of it that's = simple yet precise. >=20 > 4) Section 4.2 would be a lot clearer if you just said that the = well-known location is ONLY defined for the HTTPS URI scheme. >=20 > 5) Why not define a media type for JRD? You can instruct clients to = also accept application/json if you're worried about bad server = configurations. >=20 > 6) What's the motivation for expires, given that HTTP caching = information is already available? Have you considered the interaction = between them? >=20 > 7) Section 4.4.5 "user's preferred link relation." --> "user's = preferred link relation type." (and likely elsewhere). >=20 > 8) RFC5988 defines the "target IRI" as what's at the end of the link; = here, "linked resource" is used (e.g., 4.4.5.[2,3]). Suggest "target = resource" as a way to tie them together conceptually. >=20 > 9) Similarly, an important concept in 5988 is the "context" of the = link; suggest saying that the context of all of these links is the = subject(s). >=20 > 10) What if a target resource supports multiple media types for the = same relation? Suggest allowing multiple values in "type." >=20 > 11) 4.5 says "WebFinger requests can include a parameter = specifying..." What kind of parameter? Tie it back to what happens in = 4.1. >=20 > 12) 4.5 says "WebFinger is agnostic regarding the scheme of such a = URI..." I think you mean "neutral", unless the protocol really = believes that the scheme is unknowable. >=20 > Lucky 13) "For resources associated with a user account at a host..." = --> "To perform a webfinger lookup on an account specific to the host = being queried..." >=20 > 14) In section 7 (and likely elsewhere), you should use the full URL, = not just the path /.well-known/webfinger, to make it clear that this is = just over HTTPS. >=20 > Cheers, >=20 >=20 > * I'm not INTENTIONALLY trolling here; if it starts a fight, it's not = my fault. >=20 > -- > Mark Nottingham http://www.mnot.net/ >=20 >=20 >=20 -- Mark Nottingham http://www.mnot.net/ From evan@status.net Tue Feb 5 07:00:21 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 4857521F881D for ; Tue, 5 Feb 2013 07:00:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wquzZRUl2rmT for ; Tue, 5 Feb 2013 07:00:20 -0800 (PST) Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id 372DC21F8506 for ; Tue, 5 Feb 2013 07:00:19 -0800 (PST) Received: from [10.0.1.34] (modemcable064.24-130-66.mc.videotron.ca [66.130.24.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id B892E8D41BE for ; Tue, 5 Feb 2013 15:14:21 +0000 (UTC) Message-ID: <51111E82.5060709@status.net> Date: Tue, 05 Feb 2013 10:00:18 -0500 From: Evan Prodromou User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: webfinger@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [webfinger] Responses on draft 09 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, 05 Feb 2013 15:00:21 -0000 I've done a last review of the document. +1; it's ready to go. -Evan -- Evan Prodromou, CEO and Founder, StatusNet Inc. 1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7 E: evan@status.net P: +1-514-554-3826 From evan@e14n.com Tue Feb 5 12:57:44 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 2C7C921F8CF6 for ; Tue, 5 Feb 2013 12:57:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZwcY05gjY3NL for ; Tue, 5 Feb 2013 12:57:36 -0800 (PST) Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF0821F859A for ; Tue, 5 Feb 2013 12:57:34 -0800 (PST) Received: from [10.0.1.34] (modemcable064.24-130-66.mc.videotron.ca [66.130.24.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id 12A568D41BE for ; Tue, 5 Feb 2013 21:11:37 +0000 (UTC) Message-ID: <5111723C.6050804@e14n.com> Date: Tue, 05 Feb 2013 15:57:32 -0500 From: Evan Prodromou Organization: e14n User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: webfinger@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [webfinger] webfinger node.js module 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, 05 Feb 2013 20:57:44 -0000 The webfinger node.js module in npm now supports draft 09 of the spec. https://npmjs.org/package/webfinger node.js users should be able to install it with npm install webfinger I'm looking forward to testing it with other implementations. -Evan -- Evan Prodromou, e14n Inc. 1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7 E: evan@e14n.com P: +1-514-554-3826 From gsalguei@cisco.com Tue Feb 5 13:19: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 BFBC821F8681 for ; Tue, 5 Feb 2013 13:19:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.509 X-Spam-Level: X-Spam-Status: No, score=-10.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id woH-ol01+RhC for ; Tue, 5 Feb 2013 13:19:42 -0800 (PST) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 01B6221F86A6 for ; Tue, 5 Feb 2013 13:19:41 -0800 (PST) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r15LJfRX028752 for ; Tue, 5 Feb 2013 16:19:41 -0500 (EST) Received: from dhcp-64-102-154-246.cisco.com (dhcp-64-102-154-246.cisco.com [64.102.154.246]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r15LJf2m023433; Tue, 5 Feb 2013 16:19:41 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Gonzalo Salgueiro In-Reply-To: <5111723C.6050804@e14n.com> Date: Tue, 5 Feb 2013 16:19:41 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5B4AC4E8-38A7-4F54-848F-6057D4EC1810@cisco.com> References: <5111723C.6050804@e14n.com> To: Evan Prodromou X-Mailer: Apple Mail (2.1499) Cc: webfinger@ietf.org Subject: Re: [webfinger] webfinger node.js module 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, 05 Feb 2013 21:19:42 -0000 Cool! Thanks for doing this Evan. It would be good to do some interop = once we hit steady state on the draft (which it appears we are = mercifully getting close to :-) Cheers, Gonzalo On Feb 5, 2013, at 3:57 PM, Evan Prodromou wrote: > The webfinger node.js module in npm now supports draft 09 of the spec. >=20 > https://npmjs.org/package/webfinger >=20 > node.js users should be able to install it with >=20 > npm install webfinger >=20 > I'm looking forward to testing it with other implementations. >=20 > -Evan >=20 > --=20 > Evan Prodromou, e14n Inc. > 1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7 > E: evan@e14n.com P: +1-514-554-3826 >=20 > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger >=20 From evan@e14n.com Tue Feb 5 13:46:58 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 47F0221F84CA for ; Tue, 5 Feb 2013 13:46:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LM1lZLBZzwWE for ; Tue, 5 Feb 2013 13:46:56 -0800 (PST) Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id AC6B521F8484 for ; Tue, 5 Feb 2013 13:46:56 -0800 (PST) Received: from [10.0.1.34] (modemcable064.24-130-66.mc.videotron.ca [66.130.24.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id 72B658D4254 for ; Tue, 5 Feb 2013 22:00:59 +0000 (UTC) Message-ID: <51117DCF.8090205@e14n.com> Date: Tue, 05 Feb 2013 16:46:55 -0500 From: Evan Prodromou Organization: e14n User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "webfinger@ietf.org" References: <5111723C.6050804@e14n.com> <5B4AC4E8-38A7-4F54-848F-6057D4EC1810@cisco.com> In-Reply-To: <5B4AC4E8-38A7-4F54-848F-6057D4EC1810@cisco.com> Content-Type: multipart/alternative; boundary="------------050202070101010500030702" Subject: Re: [webfinger] webfinger node.js module 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, 05 Feb 2013 21:46:58 -0000 This is a multi-part message in MIME format. --------------050202070101010500030702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I see that the Ruby gem named 'webfinger' is also tracking the spec: https://github.com/nov/webfinger The package named 'webfinger' in pypi (the Python repository) isn't: https://github.com/jcarbaugh/python-webfinger/ ...and there's one for Perl that doesn't seem to be tracking, either: http://search.cpan.org/~tobyink/WWW-Finger-0.104/lib/WWW/Finger/Webfinger.pm I'm guessing that the ones that do start tracking will either a) use RFC 6415 and fall back to the relatively unimplemented new spec or b) vice versa. There may be some that do only one or the other. -Evan On 13-02-05 04:19 PM, Gonzalo Salgueiro wrote: > Cool! Thanks for doing this Evan. It would be good to do some interop once we hit steady state on the draft (which it appears we are mercifully getting close to :-) > > Cheers, > > Gonzalo > > On Feb 5, 2013, at 3:57 PM, Evan Prodromou wrote: > >> The webfinger node.js module in npm now supports draft 09 of the spec. >> >> https://npmjs.org/package/webfinger >> >> node.js users should be able to install it with >> >> npm install webfinger >> >> I'm looking forward to testing it with other implementations. >> >> -Evan >> >> -- >> Evan Prodromou, e14n Inc. >> 1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7 >> E: evan@e14n.com P: +1-514-554-3826 >> >> _______________________________________________ >> webfinger mailing list >> webfinger@ietf.org >> https://www.ietf.org/mailman/listinfo/webfinger >> -- Evan Prodromou, e14n Inc. 1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7 E: evan@e14n.com P: +1-514-554-3826 --------------050202070101010500030702 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
I see that the Ruby gem named 'webfinger' is also tracking the spec:
https://github.com/nov/webfinger
The package named 'webfinger' in pypi (the Python repository) isn't:
https://github.com/jcarbaugh/python-webfinger/
...and there's one for Perl that doesn't seem to be tracking, either:
http://search.cpan.org/~tobyink/WWW-Finger-0.104/lib/WWW/Finger/Webfinger.pm
I'm guessing that the ones that do start tracking will either a) use RFC 6415 and fall back to the relatively unimplemented new spec or b) vice versa.

There may be some that do only one or the other.

-Evan

On 13-02-05 04:19 PM, Gonzalo Salgueiro wrote:
Cool!  Thanks for doing this Evan.  It would be good to do some interop once we hit steady state on the draft (which it appears we are mercifully getting close to :-)

Cheers,

Gonzalo

On Feb 5, 2013, at 3:57 PM, Evan Prodromou <evan@e14n.com> wrote:


The webfinger node.js module in npm now supports draft 09 of the spec.

   https://npmjs.org/package/webfinger

node.js users should be able to install it with

   npm install webfinger

I'm looking forward to testing it with other implementations.

-Evan

-- 
Evan Prodromou, e14n Inc.
1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7
E: evan@e14n.com P: +1-514-554-3826

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




-- 
Evan Prodromou, e14n Inc.
1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7
E: evan@e14n.com P: +1-514-554-3826
--------------050202070101010500030702-- From jasnell@gmail.com Tue Feb 5 13:51: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 E45E321F8609 for ; Tue, 5 Feb 2013 13:51:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.391 X-Spam-Level: X-Spam-Status: No, score=-2.391 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b87K8OneOZdP for ; Tue, 5 Feb 2013 13:51:31 -0800 (PST) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id D82BC21F85FD for ; Tue, 5 Feb 2013 13:51:30 -0800 (PST) Received: by mail-ie0-f182.google.com with SMTP id k14so937409iea.41 for ; Tue, 05 Feb 2013 13:51:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=ECCb/KQ2iBkIiiTF4hyKfqYKdd2JnCi+GHlFiQ5Ptp8=; b=rZLV3n6UDA3s7RDlhwVcXLxPr1Rf+weM7WgIN/vRdp2YUoFnyE65A7UtsJ5uOxUXiw Q1/kd+EVNJRtIy9Al8FMQLjkGG0tZbyU1KjTZQlelHMyjdw955DU/RzRfgo4qJCY9mal woib7xa7CuQq7I6E7aNzo+3t39Ajg68PV+pFe6uqjiA4RRFplWbbQjgwZzN5Z0/sgVXt AfkZDMItBuOvF+IzfNEr01m1VVgEP/RY9Vzdx/6PmMHeCBGMMptoNKAViSS7QiH4HBhG 7yCcUTedNJtR5eZZW/3CdwPoP6mlDSX0fYesWi16mDT2/pJjmq/aH7BnbgQw3OncWrEj thBA== X-Received: by 10.50.236.38 with SMTP id ur6mr1288342igc.19.1360101086645; Tue, 05 Feb 2013 13:51:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.53.237 with HTTP; Tue, 5 Feb 2013 13:51:06 -0800 (PST) In-Reply-To: <51117DCF.8090205@e14n.com> References: <5111723C.6050804@e14n.com> <5B4AC4E8-38A7-4F54-848F-6057D4EC1810@cisco.com> <51117DCF.8090205@e14n.com> From: James M Snell Date: Tue, 5 Feb 2013 13:51:06 -0800 Message-ID: To: Evan Prodromou Content-Type: multipart/alternative; boundary=14dae9340bb320cc7f04d50136b4 Cc: "webfinger@ietf.org" Subject: Re: [webfinger] webfinger node.js module 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, 05 Feb 2013 21:51:33 -0000 --14dae9340bb320cc7f04d50136b4 Content-Type: text/plain; charset=UTF-8 My webfinger-jrd rubygem provides an impl of the jrd format, not full webfinger tho. https://rubygems.org/gems/webfinger-jrd On Tue, Feb 5, 2013 at 1:46 PM, Evan Prodromou wrote: > I see that the Ruby gem named 'webfinger' is also tracking the spec: > > https://github.com/nov/webfinger > > The package named 'webfinger' in pypi (the Python repository) isn't: > > https://github.com/jcarbaugh/python-webfinger/ > > ...and there's one for Perl that doesn't seem to be tracking, either: > > > http://search.cpan.org/~tobyink/WWW-Finger-0.104/lib/WWW/Finger/Webfinger.pm > > I'm guessing that the ones that do start tracking will either a) use RFC > 6415 and fall back to the relatively unimplemented new spec or b) vice > versa. > > There may be some that do only one or the other. > > -Evan > > > On 13-02-05 04:19 PM, Gonzalo Salgueiro wrote: > > Cool! Thanks for doing this Evan. It would be good to do some interop once we hit steady state on the draft (which it appears we are mercifully getting close to :-) > > Cheers, > > Gonzalo > > On Feb 5, 2013, at 3:57 PM, Evan Prodromou wrote: > > > The webfinger node.js module in npm now supports draft 09 of the spec. > > https://npmjs.org/package/webfinger > > node.js users should be able to install it with > > npm install webfinger > > I'm looking forward to testing it with other implementations. > > -Evan > > -- > Evan Prodromou, e14n Inc. > 1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7 > E: evan@e14n.com P: +1-514-554-3826 > > _______________________________________________ > webfinger mailing listwebfinger@ietf.orghttps://www.ietf.org/mailman/listinfo/webfinger > > > > -- > Evan Prodromou, e14n Inc. > 1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7 > E: evan@e14n.com P: +1-514-554-3826 > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > > --14dae9340bb320cc7f04d50136b4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My webfinger-jrd ruby= gem provides an impl of the jrd format, not full webfinger tho.=C2=A0



On Tue, Feb 5= , 2013 at 1:46 PM, Evan Prodromou <evan@e14n.com> wrote:
=20 =20 =20
I see that the Ruby gem named 'webfinger' is also tracking the spec:
https://github.com/nov/webfinger
The package named 'webfinger' in pypi (the Python repository) isn't:
https://github.com/jcarbaugh/python-webfinger/
...and there's one for Perl that doesn't seem to be tracking, either:
http://search.cpan.org/~t= obyink/WWW-Finger-0.104/lib/WWW/Finger/Webfinger.pm
I'm guessing that the ones that do start tracking will either a) use RFC 6415 and fall back to the relatively unimplemented new spec or b) vice versa.

There may be some that do only one or the other.

-Evan


On 13-02-05 04:19 PM, Gonzalo Salgueiro wrote:
Cool!  Thanks for doing this Evan.  It would be good to do some =
interop once we hit steady state on the draft (which it appears we are merc=
ifully getting close to :-)

Cheers,

Gonzalo

On Feb 5, 2013, at 3:57 PM, Evan Prodromou <evan@e14n.com> wrote:


The webfinger node.js module in npm now supports draft 09 of t=
he spec.

   https:=
//npmjs.org/package/webfinger

node.js users should be able to install it with

   npm install webfinger

I'm looking forward to testing it with other implementations.

-Evan

--=20
Evan Prodromou, e14n Inc.
1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7
E: evan@e14n.com P: =
+1-514-554-3826

_______________________________________________
webfinger mailing list
webfinger@ietf.org<=
/a>
https://www.ietf.org/mailman/listinfo/webfinger




--=20
Evan Prodromou, e14n Inc.
1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7
E: evan@e14n.com P: =
+1-514-554-3826

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


--14dae9340bb320cc7f04d50136b4-- From gsalguei@cisco.com Tue Feb 5 13:58:46 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 E32C021F85D0 for ; Tue, 5 Feb 2013 13:58:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.517 X-Spam-Level: X-Spam-Status: No, score=-10.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hCQv6hjAb2Rr for ; Tue, 5 Feb 2013 13:58:46 -0800 (PST) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 22EA821F847C for ; Tue, 5 Feb 2013 13:58:46 -0800 (PST) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r15LwhjP004326 for ; Tue, 5 Feb 2013 16:58:44 -0500 (EST) Received: from dhcp-64-102-154-246.cisco.com (dhcp-64-102-154-246.cisco.com [64.102.154.246]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r15Lwh62015490; Tue, 5 Feb 2013 16:58:43 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Gonzalo Salgueiro In-Reply-To: <51117DCF.8090205@e14n.com> Date: Tue, 5 Feb 2013 16:58:43 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5111723C.6050804@e14n.com> <5B4AC4E8-38A7-4F54-848F-6057D4EC1810@cisco.com> <51117DCF.8090205@e14n.com> To: Evan Prodromou X-Mailer: Apple Mail (2.1499) Cc: webfinger@ietf.org Subject: Re: [webfinger] webfinger node.js module 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, 05 Feb 2013 21:58:47 -0000 Thanks for the update. Inline... On Feb 5, 2013, at 4:46 PM, Evan Prodromou wrote: > I see that the Ruby gem named 'webfinger' is also tracking the spec: > https://github.com/nov/webfinger > The package named 'webfinger' in pypi (the Python repository) isn't: > https://github.com/jcarbaugh/python-webfinger/ > ...and there's one for Perl that doesn't seem to be tracking, either: > = http://search.cpan.org/~tobyink/WWW-Finger-0.104/lib/WWW/Finger/Webfinger.= pm There are Perl packages that are tracking the current spec. > I'm guessing that the ones that do start tracking will either a) use = RFC 6415 and fall back to the relatively unimplemented new spec or b) = vice versa. >=20 > There may be some that do only one or the other. Most I know do one or the other but if there is fallback I certainly = hope it is your vice versa option. --G >=20 > -Evan >=20 > On 13-02-05 04:19 PM, Gonzalo Salgueiro wrote: >> Cool! Thanks for doing this Evan. It would be good to do some = interop once we hit steady state on the draft (which it appears we are = mercifully getting close to :-) >>=20 >> Cheers, >>=20 >> Gonzalo >>=20 >> On Feb 5, 2013, at 3:57 PM, Evan Prodromou=20 >> >> wrote: >>=20 >>=20 >>> The webfinger node.js module in npm now supports draft 09 of the = spec. >>>=20 >>> =20 >>> https://npmjs.org/package/webfinger >>>=20 >>>=20 >>> node.js users should be able to install it with >>>=20 >>> npm install webfinger >>>=20 >>> I'm looking forward to testing it with other implementations. >>>=20 >>> -Evan >>>=20 >>> --=20 >>> Evan Prodromou, e14n Inc. >>> 1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7 >>> E:=20 >>> evan@e14n.com >>> P: +1-514-554-3826 >>>=20 >>> _______________________________________________ >>> webfinger mailing list >>>=20 >>> webfinger@ietf.org >>> https://www.ietf.org/mailman/listinfo/webfinger >>>=20 >>>=20 >>>=20 >=20 >=20 > --=20 > Evan Prodromou, e14n Inc. > 1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7 > E:=20 > evan@e14n.com P: +1-514-554-3826 > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger From paulej@packetizer.com Tue Feb 5 21:05: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 1951621F899F for ; Tue, 5 Feb 2013 21:05:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NvRfGxGgZ4b8 for ; Tue, 5 Feb 2013 21:05:29 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id F21D221F899E for ; Tue, 5 Feb 2013 21:05:28 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r1655NCn001402 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 6 Feb 2013 00:05:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1360127124; bh=jk/yt8dJMcp2pV7UxfXnjlsoFqbB3/rbvCZndhoj5Bs=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=oAv+c0LMzzCxlnkQZALeSscXkOS3Hk2GnVe7qHQjtzaGGAUK30fNC1k7rTo7S9/YR 6o2U9ktklxvwiyaQHaAULEDJyVaXHQd21Clj/mBRAp+1tegZdfq1P1DicOx4690SK7 znvqN6vAKiijA0Qf4jaA0ouf5D01ctV+gEYt9JCw= From: "Paul E. Jones" To: "'Tim Bray'" , "'Gonzalo Salgueiro'" References: <5106BFDC.2030706@ericsson.com> <51103D30.2010701@stpeter.im> <548BEEAE-E92F-461F-B06F-ABB40EB9F22C@cisco.com> In-Reply-To: Date: Wed, 6 Feb 2013 00:05:29 -0500 Message-ID: <041d01ce0427$95b16670$c1143350$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_041E_01CE03FD.ACDC6FE0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE1BCY4ftSPh+1CSwbfjBRSkBwUGQKEsM7KArFjXBkCX9tzEAF0ZkifmVXvlLA= Content-Language: en-us Cc: 'Salvatore Loreto' , 'Brad Fitzpatrick' , 'Murray Kucherawy' , 'Peter Saint-Andre' , webfinger@ietf.org Subject: Re: [webfinger] Working Group Last Call for draft-ietf-appsawg-webfinger-09 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, 06 Feb 2013 05:05:32 -0000 This is a multipart message in MIME format. ------=_NextPart_000_041E_01CE03FD.ACDC6FE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Tim, I agree that this is the URI that identifies the resource. Even so, it is the resource. Consider, "Tim submitted a suggestion to the co-author Paul" vs. "Time submitted a suggestion to the co-author identified by the given name Paul" The second form and the first are the same. I am Paul and I am identified by the given name. Likewise, "/.well-known/webfinger" is often referred to as the resource. It's not the resource, but it's the name of the resource. In section 4.1 we (I think you) introduced text to help clarify what we mean by a URI parameter. The intent was to not have to have so much verbosity every time we talk about a URI parameter. What Peter suggested to me separately is that we put the name of the well-known location in quotes. Thus, we have: A WebFinger client issues a query to the well-known [3] resource "/.well-known/webfinger" I agree we need to be precise, but it makes the text more difficult to read. What's a reasonable compromise? The Co-Author Identified by the Given Name Paul ;-) From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of Tim Bray Sent: Monday, February 04, 2013 11:49 PM To: Gonzalo Salgueiro Cc: Salvatore Loreto; Brad Fitzpatrick; Murray Kucherawy; Peter Saint-Andre; webfinger@ietf.org Subject: Re: [webfinger] Working Group Last Call for draft-ietf-appsawg-webfinger-09 One editorial issue, which has no effect on the actual normative effect. 4.2 says "A WebFinger client issues a query to the well-known [3] resource /.well-known/webfinger." Um, not really; that isn't a resource, that's part of a URI. Language should be along the lines of "It issues a query to the resource identified by the URI whose path component begins with "/.well-known/webfinger?" and whose query component MUST include include the "resource" parameter exactly...." [proceed as before]. I'd say I hate to be pedantic, but evidence would be against me. In my defense, publications of the IETF should be careful of their nomenclature about important things like resources and URIs. -T On Mon, Feb 4, 2013 at 8:08 PM, Gonzalo Salgueiro wrote: On Feb 4, 2013, at 5:58 PM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 2/1/13 10:12 AM, Brad Fitzpatrick wrote: >> +1 >> >> Looks good to me. > > Here too. I sent a bunch of editorial feedback to the authors, but I > see no substantive technical problems here. Kudos to the authors for > their work on the spec! Thanks for the extremely detailed review. Upon quick inspection the suggested edits seem perfectly reasonable. The post WGLC version will include these. Gonzalo > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iEYEARECAAYFAlEQPTAACgkQNL8k5A2w/vwi/ACgnjcwR3jTFcbfGebjtiXduydT > /gEAoK0SpA17y08zxtJB8vNidYqM9Kds > =RV/l > -----END PGP SIGNATURE----- > _______________________________________________ > 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_041E_01CE03FD.ACDC6FE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Tim,

 

I agree that this is the URI that identifies the resource.  Even = so, it is the resource.

 

Consider,

 

  “Tim submitted a suggestion to the co-author = Paul”

 

vs.

 

“Time submitted a suggestion to the co-author identified by = the given name Paul”

 

The second form and the first are the same.  I am Paul and I am = identified by the given name.  Likewise, = “/.well-known/webfinger” is often referred to as the = resource.  It’s not the resource, but it’s the name of = the resource.

 

In section 4.1 we (I think you) introduced text to help clarify what = we mean by a URI parameter.  The intent was to not have to have so = much verbosity every time we talk about a URI = parameter.

 

What Peter suggested to me separately is that we put the name of the = well-known location in quotes.  Thus, we = have:

 

    A WebFinger client issues a query to the = well-known [3] resource = “/.well-known/webfinger”

 

I agree we need to be precise, but it makes the text more difficult = to read.  What’s a reasonable = compromise?

 

The Co-Author Identified by the Given Name Paul = ;-)

 

From:= = webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On = Behalf Of Tim Bray
Sent: Monday, February 04, 2013 11:49 = PM
To: Gonzalo Salgueiro
Cc: Salvatore Loreto; Brad = Fitzpatrick; Murray Kucherawy; Peter Saint-Andre; = webfinger@ietf.org
Subject: Re: [webfinger] Working Group Last = Call for = draft-ietf-appsawg-webfinger-09

 

One editorial issue, which has no effect = on the actual normative effect.  4.2 says “A WebFinger client = issues a query to the well-known [3] resource
   = /.well-known/webfinger.” 

Um, not really; that = isn’t a resource, that’s part of a URI.  Language = should be along the lines of “It issues a query to the resource = identified by the URI whose path component begins with = “/.well-known/webfinger?” and whose query component MUST = include include the "resource" parameter exactly....” = [proceed as before].

I’d = say I hate to be pedantic, but evidence would be against me.  In my = defense, publications of the IETF should be careful of their = nomenclature about important things like resources and URIs.  = -T

 

On Mon, Feb 4, 2013 at 8:08 PM, Gonzalo Salgueiro = <gsalguei@cisco.com> = wrote:


On Feb 4, 2013, at 5:58 PM, Peter = Saint-Andre <stpeter@stpeter.im> = wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: = SHA1
>
> On 2/1/13 10:12 AM, Brad Fitzpatrick = wrote:
>> +1
>>
>> Looks good to = me.
>
> Here too. I sent a bunch of editorial feedback to = the authors, but I
> see no substantive technical problems here. = Kudos to the authors for
> their work on the = spec!

Thanks for the extremely = detailed review.  Upon quick inspection the suggested edits seem = perfectly reasonable.  The post WGLC version will include = these.

Gonzalo


>
> Peter
>
> - --
> = Peter Saint-Andre
> https://stpeter.im/
>
>
> = -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.18 = (Darwin)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> = iEYEARECAAYFAlEQPTAACgkQNL8k5A2w/vwi/ACgnjcwR3jTFcbfGebjtiXduydT
> = /gEAoK0SpA17y08zxtJB8vNidYqM9Kds
> =3DRV/l
> -----END PGP = SIGNATURE-----
> = _______________________________________________
> 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_041E_01CE03FD.ACDC6FE0-- From tbray@textuality.com Tue Feb 5 21:16:44 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 63BCE21F8936 for ; Tue, 5 Feb 2013 21:16:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.71 X-Spam-Level: X-Spam-Status: No, score=-3.71 tagged_above=-999 required=5 tests=[AWL=-0.734, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5A6kTMS3DopH for ; Tue, 5 Feb 2013 21:16:42 -0800 (PST) Received: from mail-oa0-f46.google.com (mail-oa0-f46.google.com [209.85.219.46]) by ietfa.amsl.com (Postfix) with ESMTP id 9919721F8934 for ; Tue, 5 Feb 2013 21:16:42 -0800 (PST) Received: by mail-oa0-f46.google.com with SMTP id k1so1119021oag.33 for ; Tue, 05 Feb 2013 21:16:41 -0800 (PST) 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=JQceFR+a/ynG0wATsfoMPW0Q7O5QjPtVLM4s5PeDwDg=; b=adR9MeR3wmv/UA/YAWKIfEdXNQ7MlopCO4L7yAqpYwVtdYTZsFVSO+fxfJfdOB2WgZ LcekTgjhnAefqnsod0HeIBQs/44TOA+3gh1wwhMTkx7QACtKWmeo9sgNKwYn0tHRVpGg MDrqf1+WSk4DiPR0d0h1nnkI3dIE+dgkGr2HoP+xHYk6NzZfsTF60JS1PCXysSZO2jUJ 2u/0Lb7AOPKl4qpaLVMyo8hoDbG492Q7VMlcN1cZHNjGhpY/x4VzxDg9NkPvzmyw90HK +FIqA3bbKIXgf1lig+V0sXOs3h2XsLjPBly5LUjsyQV6QmbrGRPXQLNd9bKK8yHrqTJA +z7Q== MIME-Version: 1.0 X-Received: by 10.60.13.1 with SMTP id d1mr17052632oec.55.1360127801694; Tue, 05 Feb 2013 21:16:41 -0800 (PST) Received: by 10.76.168.132 with HTTP; Tue, 5 Feb 2013 21:16:41 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: <041d01ce0427$95b16670$c1143350$@packetizer.com> References: <5106BFDC.2030706@ericsson.com> <51103D30.2010701@stpeter.im> <548BEEAE-E92F-461F-B06F-ABB40EB9F22C@cisco.com> <041d01ce0427$95b16670$c1143350$@packetizer.com> Date: Tue, 5 Feb 2013 21:16:41 -0800 Message-ID: From: Tim Bray To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=e89a8ff25008781a0b04d5076e7a X-Gm-Message-State: ALoCoQl4zB/uW8eZjndjJGGZ1Jr8XzI3y+zkpRt68Jr75rmK8ZCAPfodqLf5bNbyoPvM6UqMYaRn Cc: Gonzalo Salgueiro , Murray Kucherawy , Peter Saint-Andre , "webfinger@ietf.org" , Salvatore Loreto , Brad Fitzpatrick Subject: Re: [webfinger] Working Group Last Call for draft-ietf-appsawg-webfinger-09 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, 06 Feb 2013 05:16:44 -0000 --e89a8ff25008781a0b04d5076e7a Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable These things all live in the context of the WWW, and I think the nomenclature in http://www.w3.org/TR/webarch/ applies. The Web consists of Resources, which are identified by URIs, that=92s all there is to it. Per webfinger, there should be a resource identified by the URI =93 https://www.textuality.com/.well-known/webfinger?resource=3Dacct:tbray@text= uality.com=94 On the other hand, =93./well-known/webfinger=94 is not in any sane sense of= the word a =93resource=94, it=92s a string fragment you=92re using to assemble = a URI to identify a particular webfinger resource. The webfinger spec describes how to construct the URI to identify the resource by specifying the construction of the path and query components of the URI. These are totally conventional web operations and should be referred to by conventional web terminology. -T On Tue, Feb 5, 2013 at 9:05 PM, Paul E. Jones wrote= : > Tim,**** > > ** ** > > I agree that this is the URI that identifies the resource. Even so, it i= s > the resource.**** > > ** ** > > Consider,**** > > ** ** > > =93Tim submitted a suggestion to the co-author Paul=94**** > > ** ** > > vs.**** > > ** ** > > =93Time submitted a suggestion to the co-author identified by the given n= ame > Paul=94**** > > ** ** > > The second form and the first are the same. I am Paul and I am identifie= d > by the given name. Likewise, =93/.well-known/webfinger=94 is often refer= red to > as the resource. It=92s not the resource, but it=92s the name of the res= ource. > **** > > ** ** > > In section 4.1 we (I think you) introduced text to help clarify what we > mean by a URI parameter. The intent was to not have to have so much > verbosity every time we talk about a URI parameter.**** > > ** ** > > What Peter suggested to me separately is that we put the name of the > well-known location in quotes. Thus, we have:**** > > ** ** > > A WebFinger client issues a query to the well-known [3] resource > =93/.well-known/webfinger=94**** > > ** ** > > I agree we need to be precise, but it makes the text more difficult to > read. What=92s a reasonable compromise?**** > > ** ** > > The Co-Author Identified by the Given Name Paul ;-)**** > > ** ** > > *From:* webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] *O= n > Behalf Of *Tim Bray > *Sent:* Monday, February 04, 2013 11:49 PM > *To:* Gonzalo Salgueiro > *Cc:* Salvatore Loreto; Brad Fitzpatrick; Murray Kucherawy; Peter > Saint-Andre; webfinger@ietf.org > *Subject:* Re: [webfinger] Working Group Last Call for > draft-ietf-appsawg-webfinger-09**** > > ** ** > > One editorial issue, which has no effect on the actual normative effect. > 4.2 says =93A WebFinger client issues a query to the well-known [3] resou= rce > /.well-known/webfinger.=94 > > Um, not really; that isn=92t a resource, that=92s part of a URI. Languag= e > should be along the lines of =93It issues a query to the resource identif= ied > by the URI whose path component begins with =93/.well-known/webfinger?=94= and > whose query component MUST include include the "resource" parameter > exactly....=94 [proceed as before].**** > > I=92d say I hate to be pedantic, but evidence would be against me. In my > defense, publications of the IETF should be careful of their nomenclature > about important things like resources and URIs. -T**** > > ** ** > > On Mon, Feb 4, 2013 at 8:08 PM, Gonzalo Salgueiro > wrote:**** > > > On Feb 4, 2013, at 5:58 PM, Peter Saint-Andre wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On 2/1/13 10:12 AM, Brad Fitzpatrick wrote: > >> +1 > >> > >> Looks good to me. > > > > Here too. I sent a bunch of editorial feedback to the authors, but I > > see no substantive technical problems here. Kudos to the authors for > > their work on the spec!**** > > Thanks for the extremely detailed review. Upon quick inspection the > suggested edits seem perfectly reasonable. The post WGLC version will > include these. > > Gonzalo**** > > > > > > Peter > > > > - -- > > Peter Saint-Andre > > https://stpeter.im/ > > > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > > > iEYEARECAAYFAlEQPTAACgkQNL8k5A2w/vwi/ACgnjcwR3jTFcbfGebjtiXduydT > > /gEAoK0SpA17y08zxtJB8vNidYqM9Kds > > =3DRV/l > > -----END PGP SIGNATURE----- > > _______________________________________________ > > 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**** > > ** ** > --e89a8ff25008781a0b04d5076e7a Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
These things all live in the context of the WWW, and = I think the nomenclature in http:= //www.w3.org/TR/webarch/ applies.=A0 The Web consists of Resources, whi= ch are identified by URIs, that=92s all there is to it.

Per webfinger, there should be a resource identified by the URI =93https://www.textuality.com/.well-known/webfinger?resourc= e=3Dacct:tbray@textuality.com=94 On the other hand, =93./well-known/web= finger=94 is not in any sane sense of the word a =93resource=94, it=92s a s= tring fragment you=92re using to assemble a URI to identify a particular we= bfinger resource.

The webfinger spec describes how to construct the URI to identify= the resource by specifying the construction of the path and query componen= ts of the URI. These are totally conventional web operations and should be = referred to by conventional web terminology.=A0 -T


On Tue,= Feb 5, 2013 at 9:05 PM, Paul E. Jones <paulej@packetizer.com><= /span> wrote:

Tim,

=A0<= /p>

I agree that this is t= he URI that identifies the resource.=A0 Even so, it is the resource.=

=A0<= /p>

Consider,

=A0<= /p>

=A0 =93Tim submitted a= suggestion to the co-author Paul=94

=A0<= /p>

vs.

=A0<= /p>

=93Time submitted a s= uggestion to the co-author identified by the given name Paul=94

=A0<= /p>

The second form and th= e first are the same.=A0 I am Paul and I am identified by the given name.= =A0 Likewise, =93/.well-known/webfinger=94 is often referred to as the reso= urce.=A0 It=92s not the resource, but it=92s the name of the resource.

=A0<= /p>

In section 4.1 we (I t= hink you) introduced text to help clarify what we mean by a URI parameter. = =A0The intent was to not have to have so much verbosity every time we talk = about a URI parameter.

=A0<= /p>

What Peter suggested t= o me separately is that we put the name of the well-known location in quote= s.=A0 Thus, we have:

=A0<= /p>

=A0=A0=A0 A WebFinger = client issues a query to the well-known [3] resource =93/.well-known/webfin= ger=94

=A0<= /p>

I agree we need to be = precise, but it makes the text more difficult to read.=A0 What=92s a reason= able compromise?

=A0<= /p>

The Co-Author Identifi= ed by the Given Name Paul ;-)

=A0<= /p>

From: webfi= nger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of = Tim Bray
Sent: Monday, February 04, 2013 11:49 PM
To: Gonzalo Salgu= eiro
Cc: Salvatore Loreto; Brad Fitzpatrick; Murray Kucherawy; Pe= ter Saint-Andre; we= bfinger@ietf.org
Subject: Re: [webfinger] Working Group Last Call for draft-ietf-apps= awg-webfinger-09

=A0

One editorial issue, which has no effect on the actual normative effect.=A0= 4.2 says =93A WebFinger client issues a query to the well-known [3] resour= ce
=A0=A0 /.well-known/webfinger.=94=A0

Um, not really; that isn= =92t a resource, that=92s part of a URI.=A0 Language should be along the li= nes of =93It issues a query to the resource identified by the URI whose pat= h component begins with =93/.well-known/webfinger?=94 and whose query compo= nent MUST include include the "resource" parameter exactly....=94= [proceed as before].

I=92d say I hate to be pedantic, but evidence = would be against me.=A0 In my defense, publications of the IETF should be c= areful of their nomenclature about important things like resources and URIs= .=A0 -T

=A0=

On Mon, Feb 4, 2013 at 8:08 PM, Gonz= alo Salgueiro <g= salguei@cisco.com> wrote:


On Feb 4, 20= 13, at 5:58 PM, Peter Saint-Andre <stpeter@stpeter.im> wrote:

> -----BEGIN= PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 2/1/13 10:12 AM, Brad Fitzpatrick wrote:=
>> +1
>>
>> Looks good to me.
>
> H= ere too. I sent a bunch of editorial feedback to the authors, but I
> see no substantive technical problems here. Kudos to the authors for> their work on the spec!

Thanks for the extremely detailed review. =A0Upon quick inspection the su= ggested edits seem perfectly reasonable. =A0The post WGLC version will incl= ude these.

Gonzalo=


>
> Peter
>
>= - --
> Peter Saint-Andre
> https://stpeter.im/
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/M= acGPG2 v2.0.18 (Darwin)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net= /
>
> iEYEARECAAYFAlEQPTAACgkQNL8k5A2w/vwi/ACgnjcwR3jTFcbfGebjtiXduy= dT
> /gEAoK0SpA17y08zxtJB8vNidYqM9Kds
> =3DRV/l
> -----EN= D PGP SIGNATURE-----
> ______________________________________________= _
> webfinger mailing list
> webfinger@ietf.org
> https://www.ietf.org/mai= lman/listinfo/webfinger
>

_______________________________________________
webfinger ma= iling list
webfi= nger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger=

=A0

<= /div>

--e89a8ff25008781a0b04d5076e7a-- From paulej@packetizer.com Tue Feb 5 21:55:36 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 F20F421F86D6 for ; Tue, 5 Feb 2013 21:55:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKHuCqk01xef for ; Tue, 5 Feb 2013 21:55:35 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id CE45F21F8510 for ; Tue, 5 Feb 2013 21:55:34 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r165tUGp003670 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 6 Feb 2013 00:55:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1360130131; bh=x1MZ3WUk1hi4ZRZ0j9R3BJHVR7QWsOmP2LYJuham6+0=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=JptJaeuUdK0WfqlxduLu/zAnU5i7VCQYfLBjquws325CSvjutruEKNWUrvID80qPn Jvku1ekirbURrmcFsKlSaHPdDs/UCM+/WfUfOJ9Vx3yZMs1gDY45szjfvVQGTQeG22 i9MaJtP9PPY2MFX97ykt+5rQIrr8lt8wmi/SPjaw= From: "Paul E. Jones" To: "'SM'" , "'Salvatore Loreto'" References: <5106BFDC.2030706@ericsson.com> <5106C090.8080403@ericsson.com> <6.2.5.6.2.20130131151432.0aaf2b68@resistor.net> In-Reply-To: <6.2.5.6.2.20130131151432.0aaf2b68@resistor.net> Date: Wed, 6 Feb 2013 00:55:36 -0500 Message-ID: <044b01ce042e$965e1d00$c31a5700$@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: AQE1BCY4ftSPh+1CSwbfjBRSkBwUGQIZkwMsAqFnJiuZeHCXUA== Content-Language: en-us Cc: webfinger@ietf.org, 'James M Snell' Subject: Re: [webfinger] [apps-discuss] Working Group Last Call for draft-ietf-appsawg-webfinger-09 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, 06 Feb 2013 05:55:36 -0000 SM, > These are quick comments. > > In Section 3.1: > > "rel" : "http://webfinger.net/rel/avatar", > "type" : "image/jpeg", > "href" : "http://www.example.com/~bob/bob.jpg" > }, > { > "rel" : "http://webfinger.net/rel/profile-page", > "href" : "http://www.example.com/~bob/" > > In Section 4.3: > > In this example, the client requests the link relations of type > "http://webfinger.net/rel/profile-page" and "vcard". The server > then > > > "links" : > [ > { > "rel" : "http://webfinger.net/rel/profile-page", > "href" : "http://www.example.com/~bob/" > > In Section 4.4.4: > > > "properties" : { "http://webfinger.net/ns/name" : "Bob Smith" } > > I suggest using RFC 2606 domain names. You just want to replace all references to webfinger.net with something like example.com or webfinger.example? The reason these are here is that these are in use today. I don't mind changing them, though. What do others think? > In the references section: > > RFC 4288 should be replaced by RFC 6838. Changed. > In Section 3.3: > > "WebFinger could be used to auto-provision an email client with basic > configuration data." > > RFC 6186 describes how SRV records can be used to locate email services. > It's confusing if there is another Proposed Standard specifying another > way to do the same thing. This is just an example. That said, I'd personally prefer to use WF to solve this kind of problem than SRV records. The SRV approach presents certain administrative challenges and it's not tailored for a specific user. Rather, it applies to the whole domain. So, if you and I have accounts on packetizer.com, for example, there is no means of telling our respective mail clients which server to use if our mailbox accounts are provisioned on different servers. I believe Cyrus is still working to come up with the best solution to this provisioning issue. > In Section 4.3: > > "Support for the "rel" parameter is OPTIONAL, but RECOMMENDED on the > server." > > Either the above is recommended or it is optional. Having both does not > make sense (see RFC 2119). OK. How about this? "Servers SHOULD support for the "rel" parameter" > In Section 4.4.5.1: > > "The value of the "rel" member MUST contain exactly one URI string > or registered relation type and MUST NOT contain a space-separated > list of URIs or registered relation types." > > The MUST condition already implies the "MUST NOT" condition. What's a > URI string? Now reads: 'The value of the "rel" member MUST contain exactly one URI or registered relation type.' > In Section 7: > > "An MX record points to the mail server to which mail for the domain > should be delivered. It does not matter to the sending mail server > whether those MX records point to a server in the destination domain > or a different domain." > > It may be easier to reference RFC 5321 instead of explaining how SMTP > works. I do not think we should replace this simple explanation with a reference to a 95-page document. Nobody needs to be a mail server expert to read what is written there now. One only needs to understand the high-level idea. I'm not opposed to adding an informative reference, if you think that helps. I just don't think it does. > In Section 8: > > "Clients MUST verify that the certificate used on an HTTPS connection > is valid and accept a response only if the certificate is valid." > > Maybe the working group would like to reference RFC 6125. Separately, Peter suggested a reference to RFC 2818, so I inserted that. Should it be 6125? > "WebFinger server MUST NOT be used to provide any personal > information > to any party unless explicitly or implicitly authorized by the > person > whose information is being shared." > > I suggest using "consent" instead of "authorized". "... implicitly consented by..."? Or, "... implicitly approved by ..."? "... implicitly agreed by ..."? "... implicitly allowed by ..."? Personally, I like "authorized", but I'll take suggestions. If we want "consent", I would suggest re-wording as: "unless consent is obtained explicitly or implicitly from the person whose information is being shared" > "Implicit authorization can be determined by the user's voluntary > utilization of a service as defined by that service's relevant > terms of use or published privacy policy." > > I don't think it is up to this document to get into such advice. People > generally do not read the terms of service or privacy policy. The > guidance comes out as how to get around the "MUST NOT". James wanted that. James, can we strike that sentence? Paul From jasnell@gmail.com Tue Feb 5 22:25: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 E14E321F8964 for ; Tue, 5 Feb 2013 22:25:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.414 X-Spam-Level: X-Spam-Status: No, score=-2.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tc+rmak7tDQo for ; Tue, 5 Feb 2013 22:25:43 -0800 (PST) Received: from mail-ia0-x236.google.com (mail-ia0-x236.google.com [IPv6:2607:f8b0:4001:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 5865A21F84CE for ; Tue, 5 Feb 2013 22:25:43 -0800 (PST) Received: by mail-ia0-f182.google.com with SMTP id w33so1144431iag.41 for ; Tue, 05 Feb 2013 22:25:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=emv/x3JWILri1p+nesqAor+ykp2PPi/4dguVXpnaWW8=; b=HN0CKB+/dwkhd3fw94FXqB0eSsdvGNIDlNEQhpRKNrt5FdNCnZo1E0439InGgfpL2d GC+X7ZdEm8lZJcUMu5z4fKqBBDEn4jpBAtuyOp1+0Qwv1r6jAbyUpafzMkMltJ8RBIOv ZuPul7RZ7CAdLxVwsl0LfXa4A146sN26yqcrei1pgdEfk4DiHZETtjtmRuV9X23Na0RE lVxN6pzrbbAFA3/SPWty2DX4RwC40y75IT0QnB2Qv52kxmTtDQSF649Zu+mW1DIRQpFP LdYdKGWOerdADjILlpcQ3XhceLQaO823UwDOK22Q5LIAJH3CyGj0MhLdgFzUbPcR2nmz nnKA== X-Received: by 10.50.7.231 with SMTP id m7mr4102343iga.0.1360131942853; Tue, 05 Feb 2013 22:25:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.53.237 with HTTP; Tue, 5 Feb 2013 22:25:22 -0800 (PST) In-Reply-To: <044b01ce042e$965e1d00$c31a5700$@packetizer.com> References: <5106BFDC.2030706@ericsson.com> <5106C090.8080403@ericsson.com> <6.2.5.6.2.20130131151432.0aaf2b68@resistor.net> <044b01ce042e$965e1d00$c31a5700$@packetizer.com> From: James M Snell Date: Tue, 5 Feb 2013 22:25:22 -0800 Message-ID: To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=f46d04462dd84d2cc304d5086558 Cc: Salvatore Loreto , SM , "webfinger@ietf.org" Subject: Re: [webfinger] [apps-discuss] Working Group Last Call for draft-ietf-appsawg-webfinger-09 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, 06 Feb 2013 06:25:44 -0000 --f46d04462dd84d2cc304d5086558 Content-Type: text/plain; charset=UTF-8 So long as it remains clear that consent can be explicit or implicit... that's fine. On Tue, Feb 5, 2013 at 9:55 PM, Paul E. Jones wrote: > [snip] > > > "WebFinger server MUST NOT be used to provide any personal > > information > > to any party unless explicitly or implicitly authorized by the > > person > > whose information is being shared." > > > > I suggest using "consent" instead of "authorized". > > "... implicitly consented by..."? > > Or, > "... implicitly approved by ..."? > "... implicitly agreed by ..."? > "... implicitly allowed by ..."? > > Personally, I like "authorized", but I'll take suggestions. If we want > "consent", I would suggest re-wording as: > > "unless consent is obtained explicitly or implicitly from the person whose > information is being shared" > > > "Implicit authorization can be determined by the user's voluntary > > utilization of a service as defined by that service's relevant > > terms of use or published privacy policy." > > > > I don't think it is up to this document to get into such advice. People > > generally do not read the terms of service or privacy policy. The > > guidance comes out as how to get around the "MUST NOT". > > James wanted that. > > James, can we strike that sentence? > > Paul > > > --f46d04462dd84d2cc304d5086558 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

So long as it remains clear that consent can be explicit o= r implicit... that's fine.

On Tue, Fe= b 5, 2013 at 9:55 PM, Paul E. Jones <paulej@packetizer.com> wrote:
[snip]

> =C2=A0 =C2=A0"WebFinger server MUST NOT be used to provide any pe= rsonal
> information
> =C2=A0 =C2=A0 to any party unless explicitly or implicitly authorized = by the
> person
> =C2=A0 =C2=A0 whose information is being shared."
>
> I suggest using "consent" instead of "authorized".=

"... implicitly consented by..."?

Or,
"... implicitly approved by ..."?
"... implicitly agreed by ..."?
"... implicitly allowed by ..."?

Personally, I like "authorized", but I'll take suggestions. = =C2=A0If we want
"consent", I would suggest re-wording as:

"unless consent is obtained explicitly or implicitly from the person w= hose
information is being shared"

> =C2=A0 =C2=A0"Implicit authorization can be determined by the use= r's voluntary
> =C2=A0 =C2=A0 utilization of a service as defined by that service'= s relevant
> =C2=A0 =C2=A0 terms of use or published privacy policy."
>
> I don't think it is up to this document to get into such advice. = =C2=A0People
> generally do not read the terms of service or privacy policy. =C2=A0Th= e
> guidance comes out as how to get around the "MUST NOT".

James wanted that.

James, can we strike that sentence?

Paul



--f46d04462dd84d2cc304d5086558-- From paulej@packetizer.com Tue Feb 5 22:57:40 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 1047021F8596 for ; Tue, 5 Feb 2013 22:57:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k6w4aBTKuV14 for ; Tue, 5 Feb 2013 22:57:39 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 05EB421F853E for ; Tue, 5 Feb 2013 22:57:38 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r166vcoD007124 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 6 Feb 2013 01:57:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1360133858; bh=oGMPcKCNnMtaY0lk/ZEuf0/764Mc6Ryy1dLqINplv7I=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=olslKzWBYs37j5n7X3v58G7exr7ssi0yWKakC7ACy0Gu4YQBpezIUw3J98kw5i23Z tRlYLYNfY/RN3SWcLuRudVb3leyIl0Id/5JHntBpAor9XTIECj2nDXgADyWrYAMM1a I3ppiFh0NhycrL/DNKQ9qcVAqXEj/+bieCelXJ0M= From: "Paul E. Jones" To: "'Mark Nottingham'" , References: In-Reply-To: Date: Wed, 6 Feb 2013 01:57:44 -0500 Message-ID: <046e01ce0437$43df8ec0$cb9eac40$@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: AQK/nJvLr+z8azcZ5q9IuXWd/66Ki5aJKB+A Content-Language: en-us Subject: Re: [webfinger] [apps-discuss] WGLC feedback on webfinger-09 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, 06 Feb 2013 06:57:40 -0000 Mark, > 1) The introduction seems to be missing a vital bit of information: that > the Whole Point -- the Big Trick -- that WebFinger performs is (AIUI) > that you can use an identifier that might not be usable as a locator > (e.g., a mailto: uri, an acct: uri) as a locator. In that sense, it's > really just a more real-world-usable URN lookup facility*. > > This is really important to include in the abstract as well as the > introduction, because without it, WF just seems like a silly indirection > mechanism on top of HTTP. Do you have suggested wording? As I pondered on the abstract, I only made it more complex. > 2) The examples use unregistered link relations types > ; > specifically, "blog" and "vcard". Naughty. Yeah, but there is an intent to register both of those. You're the expert here: any reason these could not be registered for their intended purposes? (We can use URIs here, but the group preferred to use these type names.) > 3) The text in section 4.1 isn't precise enough; consider the "=" and > "&" characters, which are NOT required to be percent-encoded by RFC3986 > section 2.1. Also, the things that section is defining are not "URI > parameters" (which is things after a semicolon in a path segment); it's > a query string format. Really, what you want to do is either: a) > reference or re-define > www-form-urlencoded-encoding-algorithm>, or b) define a subset of it > that's simple yet precise. I forgot who offered this text. It might have been either Tim or Dick. I received other suggested wording. I currently have this: "This specification defines URI parameters that are passed from the client to the server when issuing a request. These parameters, "resource" and "rel", and the parameter values are included in the "query" component of the URI (see Section 3.4 of RFC 3986). To construct the "query" component, the client performs the following steps. First, each parameter value is percent-encoded as per Section 2.1 of RFC 3986. Next, the client constructs a string to be placed in the query component by concatenating the name of the first parameter together with an equal sign ("=") and the percent-encoded parameter value. For any subsequent parameters, the client appends an ampersand ("&") to the string, the name of the next parameter, an equal sign, and the parameter value (percent-encoded as needed). The client MUST NOT insert any spaces while constructing the string. The order in which the client places each attribute-and-value pair within the query component is unspecified." Exactly what should we change? > 4) Section 4.2 would be a lot clearer if you just said that the well- > known location is ONLY defined for the HTTPS URI scheme. There are several things said in that section that are not related to HTTPS. Exactly what are you suggesting we change? > 5) Why not define a media type for JRD? You can instruct clients to also > accept application/json if you're worried about bad server > configurations. This was discussed separately. What's the point of an application type for a JSON object that exists only in this context? There do not seem to be many people defining JSON-specific sub-types, either. There are a gazillion +xml registrations and it's a bit of a mess, IMO. > 6) What's the motivation for expires, given that HTTP caching > information is already available? Have you considered the interaction > between them? Expires is defined in XRD and the already-defined JRD in RFC 6415. There is no discussion on the interaction between the HTTP caching and the JRD expires value. But, these are at two different layers in the stack. Whatever generates a JRD may be a level removed from the HTTP server. Likewise on the receiving end that processes a JRD. > 7) Section 4.4.5 "user's preferred link relation." --> "user's preferred > link relation type." (and likely elsewhere). This is referring to multiple link relations of the same type. If there are multiple link relations of the same type, the first one is the user's preferred link relation. That is, if I insert three link relations of type "avatar" into a JRD, the first one if my preferred avatar. > 8) RFC5988 defines the "target IRI" as what's at the end of the link; > here, "linked resource" is used (e.g., 4.4.5.[2,3]). Suggest "target > resource" as a way to tie them together conceptually. Just replace "linked resource" with "target resource"? > 9) Similarly, an important concept in 5988 is the "context" of the link; > suggest saying that the context of all of these links is the subject(s). Can you suggest words to add? > 10) What if a target resource supports multiple media types for the same > relation? Suggest allowing multiple values in "type." This would require a change in the syntax, which I'd rather not do at this point. However, this can be accomplished by defining two array elements, both having the same "rel" value, but having a different "type" value. > 11) 4.5 says "WebFinger requests can include a parameter specifying..." > What kind of parameter? Tie it back to what happens in 4.1. This is just the "resource" parameter. Perhaps it's clearer if written this way: 'WebFinger requests can include a "resource" parameter specifying...' > 12) 4.5 says "WebFinger is agnostic regarding the scheme of such a > URI..." I think you mean "neutral", unless the protocol really > believes that the scheme is unknowable. OK, I'll change "agnostic" to "neutral". > Lucky 13) "For resources associated with a user account at a host..." --> > "To perform a webfinger lookup on an account specific to the host being > queried..." OK > 14) In section 7 (and likely elsewhere), you should use the full URL, > not just the path /.well-known/webfinger, to make it clear that this is > just over HTTPS. Are you referring to the examples? That is what the protocol would look like on the wire. If you're referring to the text like this: 'When a query is issued to "/.well-known/webfinger", the web server...' The challenge there is that I need a hostname and I would not want to put "example.com" there. Perhaps it might be better to just say: 'When a query is issued to the WebFinger resource, the web server...' But, that would not help clarify the use of HTTPS. But, use of HTTPS is stated so many times in the doc, I don't think people will screw that up. Thanks! Paul From paulej@packetizer.com Tue Feb 5 23:18:40 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 B0D1421F8921 for ; Tue, 5 Feb 2013 23:18:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2uK0J8fcTfe for ; Tue, 5 Feb 2013 23:18:36 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id A549821F8645 for ; Tue, 5 Feb 2013 23:18:36 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r167IVNx008020 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 6 Feb 2013 02:18:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1360135112; bh=+NcPlXHqRR7nbSwcZcCnsqyDKDdlq1VLyIQG6tRmxMU=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=cy8qbDBNaisz7dH81+IRtxNu39kQpqwkF2BF/kaT509CB6K5UDsALBeyN7MF1eYQy psEA5YTjs76/cD+t70Z8nv83U9pbI4iGGHinJ0u/oXVS0XLo8ApJWoDb0pwLG3+osa 1beRazBhQXDzmYv9gkQafxAf1fALOfm2IYANDnzw= From: "Paul E. Jones" To: "'Tim Bray'" References: <5106BFDC.2030706@ericsson.com> <51103D30.2010701@stpeter.im> <548BEEAE-E92F-461F-B06F-ABB40EB9F22C@cisco.com> <041d01ce0427$95b16670$c1143350$@packetizer.com> In-Reply-To: Date: Wed, 6 Feb 2013 02:18:37 -0500 Message-ID: <047001ce043a$2eee0c50$8cca24f0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0471_01CE0410.4619D910" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE1BCY4ftSPh+1CSwbfjBRSkBwUGQKEsM7KArFjXBkCX9tzEAF0ZkifAfmawQgA8QJQm5k+wR+g Content-Language: en-us Cc: 'Gonzalo Salgueiro' , 'Murray Kucherawy' , 'Peter Saint-Andre' , webfinger@ietf.org, 'Salvatore Loreto' , 'Brad Fitzpatrick' Subject: Re: [webfinger] Working Group Last Call for draft-ietf-appsawg-webfinger-09 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, 06 Feb 2013 07:18:40 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0471_01CE0410.4619D910 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Ok, too tired to argue ;-) You're right, but. darn, that's verbose. It now reads: 'A WebFinger client issues a query to the well-known [3] resource identified by the URI whose path component begins with "/.well-known/webfinger" and whose query component MUST include the "resource" parameter exactly once and set to the value of the URI for which information is being sought.' To avoid further verbosity, I tried to sidestep the issue by replacing "/.well-known/webfinger" in the document (not the examples, but just the prose). Those changes are: Section 6: "As with all web resources, access to the WebFinger resource ..." Section 7: "When a query is issued to the WebFinger resource, ..." "This WebFinger service URL does not need to point to the well-known WebFinger location on the hosting service provider server." Are those other changes OK? Paul From: Tim Bray [mailto:tbray@textuality.com] Sent: Wednesday, February 06, 2013 12:17 AM To: Paul E. Jones Cc: Gonzalo Salgueiro; Salvatore Loreto; Brad Fitzpatrick; Murray Kucherawy; Peter Saint-Andre; webfinger@ietf.org Subject: Re: [webfinger] Working Group Last Call for draft-ietf-appsawg-webfinger-09 These things all live in the context of the WWW, and I think the nomenclature in http://www.w3.org/TR/webarch/ applies. The Web consists of Resources, which are identified by URIs, that's all there is to it. Per webfinger, there should be a resource identified by the URI "https://www.textuality.com/.well-known/webfinger?resource=acct:tbray@textua lity.com" On the other hand, "./well-known/webfinger" is not in any sane sense of the word a "resource", it's a string fragment you're using to assemble a URI to identify a particular webfinger resource. The webfinger spec describes how to construct the URI to identify the resource by specifying the construction of the path and query components of the URI. These are totally conventional web operations and should be referred to by conventional web terminology. -T On Tue, Feb 5, 2013 at 9:05 PM, Paul E. Jones wrote: Tim, I agree that this is the URI that identifies the resource. Even so, it is the resource. Consider, "Tim submitted a suggestion to the co-author Paul" vs. "Time submitted a suggestion to the co-author identified by the given name Paul" The second form and the first are the same. I am Paul and I am identified by the given name. Likewise, "/.well-known/webfinger" is often referred to as the resource. It's not the resource, but it's the name of the resource. In section 4.1 we (I think you) introduced text to help clarify what we mean by a URI parameter. The intent was to not have to have so much verbosity every time we talk about a URI parameter. What Peter suggested to me separately is that we put the name of the well-known location in quotes. Thus, we have: A WebFinger client issues a query to the well-known [3] resource "/.well-known/webfinger" I agree we need to be precise, but it makes the text more difficult to read. What's a reasonable compromise? The Co-Author Identified by the Given Name Paul ;-) From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of Tim Bray Sent: Monday, February 04, 2013 11:49 PM To: Gonzalo Salgueiro Cc: Salvatore Loreto; Brad Fitzpatrick; Murray Kucherawy; Peter Saint-Andre; webfinger@ietf.org Subject: Re: [webfinger] Working Group Last Call for draft-ietf-appsawg-webfinger-09 One editorial issue, which has no effect on the actual normative effect. 4.2 says "A WebFinger client issues a query to the well-known [3] resource /.well-known/webfinger." Um, not really; that isn't a resource, that's part of a URI. Language should be along the lines of "It issues a query to the resource identified by the URI whose path component begins with "/.well-known/webfinger?" and whose query component MUST include include the "resource" parameter exactly...." [proceed as before]. I'd say I hate to be pedantic, but evidence would be against me. In my defense, publications of the IETF should be careful of their nomenclature about important things like resources and URIs. -T On Mon, Feb 4, 2013 at 8:08 PM, Gonzalo Salgueiro wrote: On Feb 4, 2013, at 5:58 PM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 2/1/13 10:12 AM, Brad Fitzpatrick wrote: >> +1 >> >> Looks good to me. > > Here too. I sent a bunch of editorial feedback to the authors, but I > see no substantive technical problems here. Kudos to the authors for > their work on the spec! Thanks for the extremely detailed review. Upon quick inspection the suggested edits seem perfectly reasonable. The post WGLC version will include these. Gonzalo > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iEYEARECAAYFAlEQPTAACgkQNL8k5A2w/vwi/ACgnjcwR3jTFcbfGebjtiXduydT > /gEAoK0SpA17y08zxtJB8vNidYqM9Kds > =RV/l > -----END PGP SIGNATURE----- > _______________________________________________ > 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_0471_01CE0410.4619D910 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ok, too tired to argue ;-)  You’re right, but… darn, = that’s verbose.

 

It now reads:

 

‘A WebFinger client issues a query to the well-known [3] = resource identified by the URI whose path component begins with = “/.well-known/webfinger” and whose query component MUST = include the “resource” parameter exactly once and set to the = value of the URI for which information is being = sought.’

 

To avoid further verbosity, I tried to sidestep the issue by = replacing “/.well-known/webfinger” in the document (not the = examples, but just the prose).  Those changes = are:

 

Section 6:

“As with all web resources, access to the WebFinger resource = ...”

 

Section 7:

“When a query is issued to the WebFinger resource, = ...”

“This WebFinger service URL does not need to point to the = well-known WebFinger location on the hosting service provider = server.”

 

Are those other changes OK?

 

Paul

 

From:= = Tim Bray [mailto:tbray@textuality.com]
Sent: Wednesday, = February 06, 2013 12:17 AM
To: Paul E. Jones
Cc: = Gonzalo Salgueiro; Salvatore Loreto; Brad Fitzpatrick; Murray Kucherawy; = Peter Saint-Andre; webfinger@ietf.org
Subject: Re: [webfinger] = Working Group Last Call for = draft-ietf-appsawg-webfinger-09

 

These things all live in the context of = the WWW, and I think the nomenclature in http://www.w3.org/TR/webarch/ = applies.  The Web consists of Resources, which are identified by = URIs, that’s all there is to it.

Per webfinger, there = should be a resource identified by the URI “https://www.textuality.com/.well-known/webfinger?re= source=3Dacct:tbray@textuality.com” On the other hand, = “./well-known/webfinger” is not in any sane sense of the = word a “resource”, it’s a string fragment you’re = using to assemble a URI to identify a particular webfinger = resource.

The webfinger spec = describes how to construct the URI to identify the resource by = specifying the construction of the path and query components of the URI. = These are totally conventional web operations and should be referred to = by conventional web terminology.  -T

 

On Tue, Feb 5, 2013 at 9:05 PM, Paul E. Jones <paulej@packetizer.com> = wrote:

Tim,

 

I agree that this is the URI that identifies the resource.  Even = so, it is the resource.

 

Consider,

 

  “Tim submitted a suggestion to the co-author = Paul”

 

vs.

 

“Time submitted a suggestion to the co-author identified by the = given name Paul”

 

The second form and the first are the same.  I am Paul and I am = identified by the given name.  Likewise, = “/.well-known/webfinger” is often referred to as the = resource.  It’s not the resource, but it’s the name of = the resource.

 

In section 4.1 we (I think you) introduced text to help clarify what = we mean by a URI parameter.  The intent was to not have to have so = much verbosity every time we talk about a URI = parameter.

 

What Peter suggested to me separately is that we put the name of the = well-known location in quotes.  Thus, we = have:

 

    A WebFinger client issues a query to the = well-known [3] resource = “/.well-known/webfinger”

 

I agree we need to be precise, but it makes the text more difficult = to read.  What’s a reasonable = compromise?

 

The Co-Author Identified by the Given Name Paul = ;-)

 

From:= = webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of = Tim Bray
Sent: Monday, February 04, 2013 11:49 = PM
To: Gonzalo Salgueiro
Cc: Salvatore Loreto; Brad = Fitzpatrick; Murray Kucherawy; Peter Saint-Andre; webfinger@ietf.org
Subject: Re: = [webfinger] Working Group Last Call for = draft-ietf-appsawg-webfinger-09

 <= /o:p>

One editorial = issue, which has no effect on the actual normative effect.  4.2 = says “A WebFinger client issues a query to the well-known [3] = resource
   /.well-known/webfinger.”  =

Um, not really; that isn’t a resource, that’s part = of a URI.  Language should be along the lines of “It issues a = query to the resource identified by the URI whose path component begins = with “/.well-known/webfinger?” and whose query component = MUST include include the "resource" parameter = exactly....” [proceed as before].

I’d = say I hate to be pedantic, but evidence would be against me.  In my = defense, publications of the IETF should be careful of their = nomenclature about important things like resources and URIs.  = -T

 <= /p>

On Mon, Feb = 4, 2013 at 8:08 PM, Gonzalo Salgueiro <gsalguei@cisco.com> = wrote:


On Feb 4, = 2013, at 5:58 PM, Peter Saint-Andre <stpeter@stpeter.im> wrote:

> = -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On = 2/1/13 10:12 AM, Brad Fitzpatrick wrote:
>> = +1
>>
>> Looks good to me.
>
> Here too. I = sent a bunch of editorial feedback to the authors, but I
> see no = substantive technical problems here. Kudos to the authors for
> = their work on the spec!

Thanks for = the extremely detailed review.  Upon quick inspection the suggested = edits seem perfectly reasonable.  The post WGLC version will = include these.

Gonzalo


>
= > Peter
>
> - --
> Peter Saint-Andre
> https://stpeter.im/
>
>
> = -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.18 = (Darwin)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> = iEYEARECAAYFAlEQPTAACgkQNL8k5A2w/vwi/ACgnjcwR3jTFcbfGebjtiXduydT
> = /gEAoK0SpA17y08zxtJB8vNidYqM9Kds
> =3DRV/l
> -----END PGP = SIGNATURE-----
> = _______________________________________________
> 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

 <= /o:p>

 

------=_NextPart_000_0471_01CE0410.4619D910-- From sm@resistor.net Tue Feb 5 23:55:19 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 D558721F8951 for ; Tue, 5 Feb 2013 23:55:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oa3WIcZ5071G for ; Tue, 5 Feb 2013 23:55:18 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 86F2F21F89B2 for ; Tue, 5 Feb 2013 23:55:17 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r167t1fh027243; Tue, 5 Feb 2013 23:55:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1360137307; bh=gj/fxNiAqAYLwEKAOb41Mluptgsulw6Y1nUNYGGqpYM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=EfYssro9HHqTFRDgxZodzwKlWE7LkpqnP2kGJXhwCPL4mncaJTT7/5JMdgA5yPKXP PvuZbDl/mHMOMkNkIm1LaPtw6rwBbnmYN8dRbhMQXDQUELs1nWDODNAQlHezJ6WNte dV3oROtwWVzfmEx/Lpwcb6mCBmKRaCtKuBDOQkpM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1360137307; i=@resistor.net; bh=gj/fxNiAqAYLwEKAOb41Mluptgsulw6Y1nUNYGGqpYM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=MtLbIzzps0CpZ7v1sQZpZ71z48gnwapd8coHJW3dKRJ003avG58Mxso4hn01AVsN+ Jv2DhLVxKXRX8mrWvU+7neAeYBQGH0mfCrZRAE+q4HtgM4xRgdfksBjyOb4jWCK4Qf VJQ2yhdIh07kJKfpfywYuv/WjY0p0LDMKT2WqiPE= Message-Id: <6.2.5.6.2.20130205233403.0dd93528@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 05 Feb 2013 23:38:13 -0800 To: James M Snell From: SM In-Reply-To: References: <5106BFDC.2030706@ericsson.com> <5106C090.8080403@ericsson.com> <6.2.5.6.2.20130131151432.0aaf2b68@resistor.net> <044b01ce042e$965e1d00$c31a5700$@packetizer.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailman-Approved-At: Tue, 05 Feb 2013 23:58:42 -0800 Cc: Salvatore Loreto , webfinger@ietf.org, "Paul E. Jones" Subject: Re: [webfinger] [apps-discuss] Working Group Last Call for draft-ietf-appsawg-webfinger-09 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, 06 Feb 2013 07:55:19 -0000 Hi James, At 22:25 05-02-2013, James M Snell wrote: >So long as it remains clear that consent can be explicit or >implicit... that's fine. It may be better not to get into whether the consent is explicit or implicit. if the working group wants the "consent" to be clear it may turn into a non-webfinger discussion. Regards, -sm From perpetual-tripper@wwelves.org Wed Feb 6 00:32:48 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 6094321F8548 for ; Wed, 6 Feb 2013 00:32:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tLGFNwD893wf for ; Wed, 6 Feb 2013 00:32:47 -0800 (PST) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) by ietfa.amsl.com (Postfix) with ESMTP id 6255421F8546 for ; Wed, 6 Feb 2013 00:32:47 -0800 (PST) Received: from mfilter23-d.gandi.net (mfilter23-d.gandi.net [217.70.178.151]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id 18BD241C07C; Wed, 6 Feb 2013 09:32:36 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter23-d.gandi.net Received: from relay5-d.mail.gandi.net ([217.70.183.197]) by mfilter23-d.gandi.net (mfilter23-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id aFCojc8ZSsUm; Wed, 6 Feb 2013 09:32:34 +0100 (CET) X-Originating-IP: 217.11.53.243 Received: from localhost (mail.heahdk.net [217.11.53.243]) (Authenticated sender: perpetual-tripper@wwelves.org) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id AD60741C051; Wed, 6 Feb 2013 09:32:34 +0100 (CET) Content-Type: text/plain; charset=UTF-8 From: =?utf-8?q?=E2=98=AE_elf_Pavlik_=E2=98=AE?= To: Evan Prodromou In-reply-to: <5111723C.6050804@e14n.com> References: <5111723C.6050804@e14n.com> Date: Wed, 06 Feb 2013 08:32:33 +0000 Message-Id: <1360139521-sup-8411@heahdk.net> User-Agent: Sup/0.12.1 Content-Transfer-Encoding: quoted-printable Cc: webfinger Subject: Re: [webfinger] webfinger node.js module 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, 06 Feb 2013 08:32:48 -0000 Excerpts from Evan Prodromou's message of 2013-02-05 20:57:32 +0000: > The webfinger node.js module in npm now supports draft 09 of the spec. >=20 > https://npmjs.org/package/webfinger >=20 > node.js users should be able to install it with >=20 > npm install webfinger >=20 > I'm looking forward to testing it with other implementations. great! thanks for sharing it Evan :) From tbray@textuality.com Wed Feb 6 08:07:21 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 401E821F84F8 for ; Wed, 6 Feb 2013 08:07:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id brMm3AsaBASa for ; Wed, 6 Feb 2013 08:07:19 -0800 (PST) Received: from mail-oa0-f50.google.com (mail-oa0-f50.google.com [209.85.219.50]) by ietfa.amsl.com (Postfix) with ESMTP id D593421F841B for ; Wed, 6 Feb 2013 08:07:17 -0800 (PST) Received: by mail-oa0-f50.google.com with SMTP id l20so1683917oag.9 for ; Wed, 06 Feb 2013 08:07:12 -0800 (PST) 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=QWhLPnMztin6Sqj84BQdDPAxZsA0YarJ+/xOAXYdnSI=; b=MJoDPYvRrfnDkRSQY0CegkXq+duPBeiJWUyl47wGgyg9gknnoz6qe7x6fwvzRoEZcw W2Y84gH/Mz3vQ6/ImUSO97qCAFUVf134sCZFDvc1OzcuRbPhA7kJHwTXBEVNq6XC5g3Z 8QKNiplTYU07Rjc28PKsqURCtlP4E90OoU64zNoaCvf97arPii2X5fPPW4j51sCa4E/j fpc4WEM77bUx10RQgC8ldQR4Nr3eNqRVydnDGE067WU2jC1hwJCVVFraGOK1fGpwpuCR xkv1LrcwcH6TMxGvaOTcbOenRBWCA22z0w20Jt5rkuesfdXZXIKRpAOS6whOoWzylAb3 zNGQ== MIME-Version: 1.0 X-Received: by 10.60.19.231 with SMTP id i7mr22621112oee.34.1360166832343; Wed, 06 Feb 2013 08:07:12 -0800 (PST) Received: by 10.76.173.38 with HTTP; Wed, 6 Feb 2013 08:07:12 -0800 (PST) X-Originating-IP: [74.198.150.217] Received: by 10.76.173.38 with HTTP; Wed, 6 Feb 2013 08:07:12 -0800 (PST) In-Reply-To: <047001ce043a$2eee0c50$8cca24f0$@packetizer.com> References: <5106BFDC.2030706@ericsson.com> <51103D30.2010701@stpeter.im> <548BEEAE-E92F-461F-B06F-ABB40EB9F22C@cisco.com> <041d01ce0427$95b16670$c1143350$@packetizer.com> <047001ce043a$2eee0c50$8cca24f0$@packetizer.com> Date: Wed, 6 Feb 2013 08:07:12 -0800 Message-ID: From: Tim Bray To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=e89a8ff1c60ae0896a04d510845f X-Gm-Message-State: ALoCoQl6eLWcJpYDHEDMwDXUFYK5/8I151HPpUlKIE1kdflDvbJqUstUo3lct/V5zJP6ymgLSvzp Cc: Gonzalo Salgueiro , Murray Kucherawy , Peter Saint-Andre , Brad Fitzpatrick , Salvatore Loreto , webfinger@ietf.org Subject: Re: [webfinger] Working Group Last Call for draft-ietf-appsawg-webfinger-09 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, 06 Feb 2013 16:07:21 -0000 --e89a8ff1c60ae0896a04d510845f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks, looks good. I see you used the string "URL"; intentional, or did you mean URI? On Feb 5, 2013 11:18 PM, "Paul E. Jones" wrote: > Ok, too tired to argue ;-) You=92re right, but=85 darn, that=92s verbose= .**** > > ** ** > > It now reads:**** > > ** ** > > =91A WebFinger client issues a query to the well-known [3] resource > identified by the URI whose path component begins with > =93/.well-known/webfinger=94 and whose query component MUST include the > =93resource=94 parameter exactly once and set to the value of the URI for= which > information is being sought.=92**** > > ** ** > > To avoid further verbosity, I tried to sidestep the issue by replacing > =93/.well-known/webfinger=94 in the document (not the examples, but just = the > prose). Those changes are:**** > > ** ** > > Section 6:**** > > =93As with all web resources, access to the WebFinger resource ...=94**** > > ** ** > > Section 7:**** > > =93When a query is issued to the WebFinger resource, ...=94**** > > =93This WebFinger service URL does not need to point to the well-known > WebFinger location on the hosting service provider server.=94**** > > ** ** > > Are those other changes OK?**** > > ** ** > > Paul**** > > ** ** > > *From:* Tim Bray [mailto:tbray@textuality.com] > *Sent:* Wednesday, February 06, 2013 12:17 AM > *To:* Paul E. Jones > *Cc:* Gonzalo Salgueiro; Salvatore Loreto; Brad Fitzpatrick; Murray > Kucherawy; Peter Saint-Andre; webfinger@ietf.org > *Subject:* Re: [webfinger] Working Group Last Call for > draft-ietf-appsawg-webfinger-09**** > > ** ** > > These things all live in the context of the WWW, and I think the > nomenclature in http://www.w3.org/TR/webarch/ applies. The Web consists > of Resources, which are identified by URIs, that=92s all there is to it. > > Per webfinger, there should be a resource identified by the URI =93 > https://www.textuality.com/.well-known/webfinger?resource=3Dacct:tbray@te= xtuality.com=94 > On the other hand, =93./well-known/webfinger=94 is not in any sane sense = of the > word a =93resource=94, it=92s a string fragment you=92re using to assembl= e a URI to > identify a particular webfinger resource.**** > > The webfinger spec describes how to construct the URI to identify the > resource by specifying the construction of the path and query components = of > the URI. These are totally conventional web operations and should be > referred to by conventional web terminology. -T**** > > ** ** > > On Tue, Feb 5, 2013 at 9:05 PM, Paul E. Jones > wrote:**** > > Tim,**** > > **** > > I agree that this is the URI that identifies the resource. Even so, it i= s > the resource.**** > > **** > > Consider,**** > > **** > > =93Tim submitted a suggestion to the co-author Paul=94**** > > **** > > vs.**** > > **** > > =93Time submitted a suggestion to the co-author identified by the given n= ame > Paul=94**** > > **** > > The second form and the first are the same. I am Paul and I am identifie= d > by the given name. Likewise, =93/.well-known/webfinger=94 is often refer= red to > as the resource. It=92s not the resource, but it=92s the name of the res= ource. > **** > > **** > > In section 4.1 we (I think you) introduced text to help clarify what we > mean by a URI parameter. The intent was to not have to have so much > verbosity every time we talk about a URI parameter.**** > > **** > > What Peter suggested to me separately is that we put the name of the > well-known location in quotes. Thus, we have:**** > > **** > > A WebFinger client issues a query to the well-known [3] resource > =93/.well-known/webfinger=94**** > > **** > > I agree we need to be precise, but it makes the text more difficult to > read. What=92s a reasonable compromise?**** > > **** > > The Co-Author Identified by the Given Name Paul ;-)**** > > **** > > *From:* webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] *O= n > Behalf Of *Tim Bray > *Sent:* Monday, February 04, 2013 11:49 PM > *To:* Gonzalo Salgueiro > *Cc:* Salvatore Loreto; Brad Fitzpatrick; Murray Kucherawy; Peter > Saint-Andre; webfinger@ietf.org > *Subject:* Re: [webfinger] Working Group Last Call for > draft-ietf-appsawg-webfinger-09**** > > **** > > One editorial issue, which has no effect on the actual normative effect. > 4.2 says =93A WebFinger client issues a query to the well-known [3] resou= rce > /.well-known/webfinger.=94 > > Um, not really; that isn=92t a resource, that=92s part of a URI. Languag= e > should be along the lines of =93It issues a query to the resource identif= ied > by the URI whose path component begins with =93/.well-known/webfinger?=94= and > whose query component MUST include include the "resource" parameter > exactly....=94 [proceed as before].**** > > I=92d say I hate to be pedantic, but evidence would be against me. In my > defense, publications of the IETF should be careful of their nomenclature > about important things like resources and URIs. -T**** > > **** > > On Mon, Feb 4, 2013 at 8:08 PM, Gonzalo Salgueiro > wrote:**** > > > On Feb 4, 2013, at 5:58 PM, Peter Saint-Andre wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On 2/1/13 10:12 AM, Brad Fitzpatrick wrote: > >> +1 > >> > >> Looks good to me. > > > > Here too. I sent a bunch of editorial feedback to the authors, but I > > see no substantive technical problems here. Kudos to the authors for > > their work on the spec!**** > > Thanks for the extremely detailed review. Upon quick inspection the > suggested edits seem perfectly reasonable. The post WGLC version will > include these. > > Gonzalo**** > > > > > > Peter > > > > - -- > > Peter Saint-Andre > > https://stpeter.im/ > > > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > > > iEYEARECAAYFAlEQPTAACgkQNL8k5A2w/vwi/ACgnjcwR3jTFcbfGebjtiXduydT > > /gEAoK0SpA17y08zxtJB8vNidYqM9Kds > > =3DRV/l > > -----END PGP SIGNATURE----- > > _______________________________________________ > > 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**** > > **** > > ** ** > --e89a8ff1c60ae0896a04d510845f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Thanks, looks good. I see you used the string "URL"= ;; intentional, or did you mean URI?

On Feb 5, 2013 11:18 PM, "Paul E. Jones&quo= t; <paulej@packetizer.com&g= t; wrote:

Ok, too tired to argue ;-)=A0 You=92re right= , but=85 darn, that=92s verbose.

=A0<= /p>

It now reads:

=A0<= /p>

=91A WebFinger client = issues a query to the well-known [3] resource identified by the URI whose p= ath component begins with =93/.well-known/webfinger=94 and whose query comp= onent MUST include the =93resource=94 parameter exactly once and set to the= value of the URI for which information is being sought.=92

=A0<= /p>

To avoid further verbo= sity, I tried to sidestep the issue by replacing =93/.well-known/webfinger= =94 in the document (not the examples, but just the prose).=A0 Those change= s are:

=A0<= /p>

Section 6:

=93As with all web resour= ces, access to the WebFinger resource ...=94

=A0

Section 7:

=93When a query is issued= to the WebFinger resource, ...=94

=93This WebFinger service URL does not need to p= oint to the well-known WebFinger location on the hosting service provider s= erver.=94

=A0<= /p>

Are those other change= s OK?

=A0<= /p>

Paul

=A0<= /p>

From: Tim Bray [mailto:tbray@textuality.com]
Sent: Wednesday, February 06, 2013 12:17 AM
To: Paul E. Jo= nes
Cc: Gonzalo Salgueiro; Salvatore Loreto; Brad Fitzpatrick; Mu= rray Kucherawy; Peter Saint-Andre; webfinger@ietf.org
Subject: Re: [webfinger] Working Group Last Call for draft-ietf-apps= awg-webfinger-09

=A0

These things all live in the context of the WWW, and I think the nomenclatu= re in http://ww= w.w3.org/TR/webarch/ applies.=A0 The Web consists of Resources, which a= re identified by URIs, that=92s all there is to it.

Per webfinger, there should be a resource identified by the URI =93https://www.textuality.com/.well-known= /webfinger?resource=3Dacct:tbray@textuality.com=94 On the other hand, = =93./well-known/webfinger=94 is not in any sane sense of the word a =93reso= urce=94, it=92s a string fragment you=92re using to assemble a URI to ident= ify a particular webfinger resource.

The webfinger spec describes how to construct = the URI to identify the resource by specifying the construction of the path= and query components of the URI. These are totally conventional web operat= ions and should be referred to by conventional web terminology.=A0 -T

=A0=

On Tue, Feb 5, 2013 at 9:05 PM, Paul= E. Jones <pa= ulej@packetizer.com> wrote:

Tim,<= /u>

=A0<= u>

I agree that this is the = URI that identifies the resource.=A0 Even so, it is the resource.=

=A0<= /p>

Consider,

=A0<= /p>

=A0 =93Tim submitted a= suggestion to the co-author Paul=94

=A0<= /p>

vs.

=A0<= /p>

=93Time submitted a su= ggestion to the co-author identified by the given name Paul=94

=A0<= /p>

The second form and th= e first are the same.=A0 I am Paul and I am identified by the given name.= =A0 Likewise, =93/.well-known/webfinger=94 is often referred to as the reso= urce.=A0 It=92s not the resource, but it=92s the name of the resource.

=A0<= /p>

In section 4.1 we (I t= hink you) introduced text to help clarify what we mean by a URI parameter. = =A0The intent was to not have to have so much verbosity every time we talk = about a URI parameter.

=A0<= /p>

What Peter suggested t= o me separately is that we put the name of the well-known location in quote= s.=A0 Thus, we have:

=A0<= /p>

=A0=A0=A0 A WebFinger = client issues a query to the well-known [3] resource =93/.well-known/webfin= ger=94

=A0<= /p>

I agree we need to be = precise, but it makes the text more difficult to read.=A0 What=92s a reason= able compromise?

=A0<= /p>

The Co-Author Identifi= ed by the Given Name Paul ;-)

=A0<= /p>

From: webfi= nger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of = Tim Bray
Sent: Monday, February 04, 2013 11:49 PM
To: Gonzalo Salgu= eiro
Cc: Salvatore Loreto; Brad Fitzpatrick; Murray Kucherawy; Pe= ter Saint-Andre; we= bfinger@ietf.org
Subject: Re: [webfinger] Working Group Last Call for draft-ietf-apps= awg-webfinger-09

=A0

One editorial issue, which has no effect on the actual normative effect.=A0= 4.2 says =93A WebFinger client issues a query to the well-known [3] resour= ce
=A0=A0 /.well-known/webfinger.=94=A0

Um, not really; that isn= =92t a resource, that=92s part of a URI.=A0 Language should be along the li= nes of =93It issues a query to the resource identified by the URI whose pat= h component begins with =93/.well-known/webfinger?=94 and whose query compo= nent MUST include include the "resource" parameter exactly....=94= [proceed as before].

I=92d say I hate to be pedantic, but evidence = would be against me.=A0 In my defense, publications of the IETF should be c= areful of their nomenclature about important things like resources and URIs= .=A0 -T

=A0=

On Mon, Feb 4, 2013 at 8:08 PM, Gonz= alo Salgueiro <g= salguei@cisco.com> wrote:


On Feb 4, 20= 13, at 5:58 PM, Peter Saint-Andre <stpeter@stpeter.im> wrote:

> -----BEGIN= PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 2/1/13 10:12 AM, Brad Fitzpatrick wrote:=
>> +1
>>
>> Looks good to me.
>
> H= ere too. I sent a bunch of editorial feedback to the authors, but I
> see no substantive technical problems here. Kudos to the authors for> their work on the spec!

Thanks for the extremely detailed review. =A0Upon quick inspection the su= ggested edits seem perfectly reasonable. =A0The post WGLC version will incl= ude these.

Gonzalo


>
> Peter
>
> - --
>= Peter Saint-Andre
> https://stpeter.im/
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/M= acGPG2 v2.0.18 (Darwin)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net= /
>
> iEYEARECAAYFAlEQPTAACgkQNL8k5A2w/vwi/ACgnjcwR3jTFcbfGebjtiXduy= dT
> /gEAoK0SpA17y08zxtJB8vNidYqM9Kds
> =3DRV/l
> -----EN= D PGP SIGNATURE-----
> ______________________________________________= _
> webfinger mailing list
> webfinger@ietf.org
> https://www.ietf.org/mai= lman/listinfo/webfinger
>

_______________________________________________
webfinger ma= iling list
webfi= nger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger=

=A0

<= /div>

=A0

--e89a8ff1c60ae0896a04d510845f-- From paulej@packetizer.com Wed Feb 6 21:37:16 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 CF97321F84D5 for ; Wed, 6 Feb 2013 21:37:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dfrObI7jjxaW for ; Wed, 6 Feb 2013 21:37:06 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 1E13421F84D3 for ; Wed, 6 Feb 2013 21:37:06 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r175axVI022527 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Feb 2013 00:37:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1360215421; bh=bfaBwFjYd9iaW+CFU9mjanGOzyqC8WpgEr1W2Qo4fdY=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=b20BEtZGp/2d61aXMJqravAUyywfkKzsumrwztnqeggjMt7WB/GX8P3DXBfsBvmV2 l/JGmIp9yutn/ewhgbINvNHwyWCpvFa75/bs4XF4phBZMuzNWp8wWvHlzHYym8M/vs RYNz8t6n7LYE0omW5cOUuuYEZwcGJDpysJeNDpLk= From: "Paul E. Jones" To: "'Tim Bray'" References: <5106BFDC.2030706@ericsson.com> <51103D30.2010701@stpeter.im> <548BEEAE-E92F-461F-B06F-ABB40EB9F22C@cisco.com> <041d01ce0427$95b16670$c1143350$@packetizer.com> <047001ce043a$2eee0c50$8cca24f0$@packetizer.com> In-Reply-To: Date: Thu, 7 Feb 2013 00:37:08 -0500 Message-ID: <071201ce04f5$2c038590$840a90b0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0713_01CE04CB.432F7960" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE1BCY4ftSPh+1CSwbfjBRSkBwUGQKEsM7KArFjXBkCX9tzEAF0ZkifAfmawQgA8QJQmwKpRsb2AfpQevKZGxwzoA== Content-Language: en-us Cc: 'Gonzalo Salgueiro' , 'Murray Kucherawy' , 'Peter Saint-Andre' , 'Brad Fitzpatrick' , 'Salvatore Loreto' , webfinger@ietf.org Subject: Re: [webfinger] Working Group Last Call for draft-ietf-appsawg-webfinger-09 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, 07 Feb 2013 05:37:16 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0713_01CE04CB.432F7960 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Actually, the revised text was using URI, but I should have used URL to be consistent with other parts of the document. Every place where we refer to the WebFinger resource, we say "URL". The acronym "URL" appears 5 times in the document. Most other places we use the term "URI" since the "href" can be any URI, the resource parameter is a URI, etc. Paul From: Tim Bray [mailto:tbray@textuality.com] Sent: Wednesday, February 06, 2013 11:07 AM To: Paul E. Jones Cc: Salvatore Loreto; Peter Saint-Andre; Murray Kucherawy; webfinger@ietf.org; Brad Fitzpatrick; Gonzalo Salgueiro Subject: RE: [webfinger] Working Group Last Call for draft-ietf-appsawg-webfinger-09 Thanks, looks good. I see you used the string "URL"; intentional, or did you mean URI? On Feb 5, 2013 11:18 PM, "Paul E. Jones" wrote: Ok, too tired to argue ;-) You're right, but. darn, that's verbose. It now reads: 'A WebFinger client issues a query to the well-known [3] resource identified by the URI whose path component begins with "/.well-known/webfinger" and whose query component MUST include the "resource" parameter exactly once and set to the value of the URI for which information is being sought.' To avoid further verbosity, I tried to sidestep the issue by replacing "/.well-known/webfinger" in the document (not the examples, but just the prose). Those changes are: Section 6: "As with all web resources, access to the WebFinger resource ..." Section 7: "When a query is issued to the WebFinger resource, ..." "This WebFinger service URL does not need to point to the well-known WebFinger location on the hosting service provider server." Are those other changes OK? Paul From: Tim Bray [mailto:tbray@textuality.com] Sent: Wednesday, February 06, 2013 12:17 AM To: Paul E. Jones Cc: Gonzalo Salgueiro; Salvatore Loreto; Brad Fitzpatrick; Murray Kucherawy; Peter Saint-Andre; webfinger@ietf.org Subject: Re: [webfinger] Working Group Last Call for draft-ietf-appsawg-webfinger-09 These things all live in the context of the WWW, and I think the nomenclature in http://www.w3.org/TR/webarch/ applies. The Web consists of Resources, which are identified by URIs, that's all there is to it. Per webfinger, there should be a resource identified by the URI "https://www.textuality.com/.well-known/webfinger?resource=acct:tbray@textua lity.com" On the other hand, "./well-known/webfinger" is not in any sane sense of the word a "resource", it's a string fragment you're using to assemble a URI to identify a particular webfinger resource. The webfinger spec describes how to construct the URI to identify the resource by specifying the construction of the path and query components of the URI. These are totally conventional web operations and should be referred to by conventional web terminology. -T On Tue, Feb 5, 2013 at 9:05 PM, Paul E. Jones wrote: Tim, I agree that this is the URI that identifies the resource. Even so, it is the resource. Consider, "Tim submitted a suggestion to the co-author Paul" vs. "Time submitted a suggestion to the co-author identified by the given name Paul" The second form and the first are the same. I am Paul and I am identified by the given name. Likewise, "/.well-known/webfinger" is often referred to as the resource. It's not the resource, but it's the name of the resource. In section 4.1 we (I think you) introduced text to help clarify what we mean by a URI parameter. The intent was to not have to have so much verbosity every time we talk about a URI parameter. What Peter suggested to me separately is that we put the name of the well-known location in quotes. Thus, we have: A WebFinger client issues a query to the well-known [3] resource "/.well-known/webfinger" I agree we need to be precise, but it makes the text more difficult to read. What's a reasonable compromise? The Co-Author Identified by the Given Name Paul ;-) From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of Tim Bray Sent: Monday, February 04, 2013 11:49 PM To: Gonzalo Salgueiro Cc: Salvatore Loreto; Brad Fitzpatrick; Murray Kucherawy; Peter Saint-Andre; webfinger@ietf.org Subject: Re: [webfinger] Working Group Last Call for draft-ietf-appsawg-webfinger-09 One editorial issue, which has no effect on the actual normative effect. 4.2 says "A WebFinger client issues a query to the well-known [3] resource /.well-known/webfinger." Um, not really; that isn't a resource, that's part of a URI. Language should be along the lines of "It issues a query to the resource identified by the URI whose path component begins with "/.well-known/webfinger?" and whose query component MUST include include the "resource" parameter exactly...." [proceed as before]. I'd say I hate to be pedantic, but evidence would be against me. In my defense, publications of the IETF should be careful of their nomenclature about important things like resources and URIs. -T On Mon, Feb 4, 2013 at 8:08 PM, Gonzalo Salgueiro wrote: On Feb 4, 2013, at 5:58 PM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 2/1/13 10:12 AM, Brad Fitzpatrick wrote: >> +1 >> >> Looks good to me. > > Here too. I sent a bunch of editorial feedback to the authors, but I > see no substantive technical problems here. Kudos to the authors for > their work on the spec! Thanks for the extremely detailed review. Upon quick inspection the suggested edits seem perfectly reasonable. The post WGLC version will include these. Gonzalo > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iEYEARECAAYFAlEQPTAACgkQNL8k5A2w/vwi/ACgnjcwR3jTFcbfGebjtiXduydT > /gEAoK0SpA17y08zxtJB8vNidYqM9Kds > =RV/l > -----END PGP SIGNATURE----- > _______________________________________________ > 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_0713_01CE04CB.432F7960 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Actually, the revised text was using URI, but I should have used URL = to be consistent with other parts of the document.  Every place = where we refer to the WebFinger resource, we say = “URL”.

 

The acronym “URL” appears 5 times in the = document.

 

Most other places we use the term “URI” since the = “href” can be any URI, the resource parameter is a URI, = etc.

 

Paul

 

From:= = Tim Bray [mailto:tbray@textuality.com]
Sent: Wednesday, = February 06, 2013 11:07 AM
To: Paul E. Jones
Cc: = Salvatore Loreto; Peter Saint-Andre; Murray Kucherawy; = webfinger@ietf.org; Brad Fitzpatrick; Gonzalo = Salgueiro
Subject: RE: [webfinger] Working Group Last Call for = draft-ietf-appsawg-webfinger-09

 

Thanks, looks good. I see you = used the string "URL"; intentional, or did you mean = URI?

On Feb 5, 2013 11:18 PM, = "Paul E. Jones" <paulej@packetizer.com> = wrote:

Ok, too tired to argue ;-)  You’re right, but… darn, = that’s verbose.

 

It now reads:

 

‘A WebFinger client issues a query to the well-known [3] = resource identified by the URI whose path component begins with = “/.well-known/webfinger” and whose query component MUST = include the “resource” parameter exactly once and set to the = value of the URI for which information is being = sought.’

 

To avoid further verbosity, I tried to sidestep the issue by = replacing “/.well-known/webfinger” in the document (not the = examples, but just the prose).  Those changes = are:

 

Section 6:

“As with all web resources, access to the WebFinger resource = ...”

 

Section 7:

“When a query is issued to the WebFinger resource, = ...”

“This WebFinger service URL does not need to point to the = well-known WebFinger location on the hosting service provider = server.”

 

Are those other changes OK?

 

Paul

 

From:= = Tim Bray [mailto:tbray@textuality.com]
Sent: Wednesday, = February 06, 2013 12:17 AM
To: Paul E. Jones
Cc: = Gonzalo Salgueiro; Salvatore Loreto; Brad Fitzpatrick; Murray Kucherawy; = Peter Saint-Andre; webfinger@ietf.org
Subject: Re: = [webfinger] Working Group Last Call for = draft-ietf-appsawg-webfinger-09

 <= /o:p>

These things all = live in the context of the WWW, and I think the nomenclature in http://www.w3.org/TR/webarch/ applies.  The = Web consists of Resources, which are identified by URIs, that’s = all there is to it.

Per webfinger, there should be a resource = identified by the URI “https://www.textuality.com/.well-known/webfinger?resour= ce=3Dacct:tbray@textuality.com” On the other hand, = “./well-known/webfinger” is not in any sane sense of the = word a “resource”, it’s a string fragment you’re = using to assemble a URI to identify a particular webfinger = resource.

The = webfinger spec describes how to construct the URI to identify the = resource by specifying the construction of the path and query components = of the URI. These are totally conventional web operations and should be = referred to by conventional web terminology.  = -T

 <= /p>

On Tue, Feb = 5, 2013 at 9:05 PM, Paul E. Jones <paulej@packetizer.com> = wrote:

Tim,

 

I agree that this is the URI that identifies the resource.  Even = so, it is the resource.

 

Consider,

 

  “Tim submitted a suggestion to the co-author = Paul”

 

vs.

 

“Time submitted a suggestion to the co-author identified by the = given name Paul”

 

The second form and the first are the same.  I am Paul and I am = identified by the given name.  Likewise, = “/.well-known/webfinger” is often referred to as the = resource.  It’s not the resource, but it’s the name of = the resource.

 

In section 4.1 we (I think you) introduced text to help clarify what = we mean by a URI parameter.  The intent was to not have to have so = much verbosity every time we talk about a URI = parameter.

 

What Peter suggested to me separately is that we put the name of the = well-known location in quotes.  Thus, we = have:

 

    A WebFinger client issues a query to the = well-known [3] resource = “/.well-known/webfinger”

 

I agree we need to be precise, but it makes the text more difficult = to read.  What’s a reasonable = compromise?

 

The Co-Author Identified by the Given Name Paul = ;-)

 

From:= = webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of = Tim Bray
Sent: Monday, February 04, 2013 11:49 = PM
To: Gonzalo Salgueiro
Cc: Salvatore Loreto; Brad = Fitzpatrick; Murray Kucherawy; Peter Saint-Andre; webfinger@ietf.org
Subject: Re: = [webfinger] Working Group Last Call for = draft-ietf-appsawg-webfinger-09

 <= /o:p>

One editorial = issue, which has no effect on the actual normative effect.  4.2 = says “A WebFinger client issues a query to the well-known [3] = resource
   /.well-known/webfinger.”  =

Um, not really; that isn’t a resource, that’s part = of a URI.  Language should be along the lines of “It issues a = query to the resource identified by the URI whose path component begins = with “/.well-known/webfinger?” and whose query component = MUST include include the "resource" parameter = exactly....” [proceed as before].

I’d = say I hate to be pedantic, but evidence would be against me.  In my = defense, publications of the IETF should be careful of their = nomenclature about important things like resources and URIs.  = -T

 <= /p>

On Mon, Feb = 4, 2013 at 8:08 PM, Gonzalo Salgueiro <gsalguei@cisco.com> = wrote:


On Feb 4, = 2013, at 5:58 PM, Peter Saint-Andre <stpeter@stpeter.im> wrote:

> = -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On = 2/1/13 10:12 AM, Brad Fitzpatrick wrote:
>> = +1
>>
>> Looks good to me.
>
> Here too. I = sent a bunch of editorial feedback to the authors, but I
> see no = substantive technical problems here. Kudos to the authors for
> = their work on the spec!

Thanks for = the extremely detailed review.  Upon quick inspection the suggested = edits seem perfectly reasonable.  The post WGLC version will = include these.

Gonzalo


>
= > Peter
>
> - --
> Peter Saint-Andre
> https://stpeter.im/
>
>
> = -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.18 = (Darwin)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> = iEYEARECAAYFAlEQPTAACgkQNL8k5A2w/vwi/ACgnjcwR3jTFcbfGebjtiXduydT
> = /gEAoK0SpA17y08zxtJB8vNidYqM9Kds
> =3DRV/l
> -----END PGP = SIGNATURE-----
> = _______________________________________________
> 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

 <= /o:p>

 <= /o:p>

------=_NextPart_000_0713_01CE04CB.432F7960-- From tbray@textuality.com Wed Feb 6 21:42: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 86A1B21E8040 for ; Wed, 6 Feb 2013 21:42:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.526 X-Spam-Level: X-Spam-Status: No, score=-3.526 tagged_above=-999 required=5 tests=[AWL=-0.550, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCd4RUHeOp7u for ; Wed, 6 Feb 2013 21:42:40 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8F52721F8233 for ; Wed, 6 Feb 2013 21:42:40 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id tb18so2361164obb.31 for ; Wed, 06 Feb 2013 21:42:40 -0800 (PST) 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=lxwxF1m1Gpk+QXT4LoWqtcnlWokc9LjKcPyu2FojMAM=; b=OjSL6mXb3c/hBW1h2MN3PS5lo9hy4J06BdjBLlmjbDMYkToxQDYv5W53irxOBz/2HR H91mWM3ul0mCuQxdfvhgjs54+q+qxSX3aGGkDvJ75Myv2ChEljqW+itFDosUC4xF83f1 GRnMokC233oFPVQsLmArXCLMTzMtjNbBkL4vN8Iv/yVS+GuiwTsjLWnxV0QCtUfQO7+r 4ftXHitMxd2kYAmMrw2Q8olSYIttgmdQydQ4BZCYkm0FVZ3ZwL8VTu2oT6yqzrWSJagV aTcUDD7lxYE8sVHwQFH7KpkvppMg7QdkGMdMKYyjn49FeIIHC+7ho6aXOrmGSnygwoXU lcww== MIME-Version: 1.0 X-Received: by 10.182.40.69 with SMTP id v5mr33842obk.57.1360215760109; Wed, 06 Feb 2013 21:42:40 -0800 (PST) Received: by 10.76.173.38 with HTTP; Wed, 6 Feb 2013 21:42:39 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: <071201ce04f5$2c038590$840a90b0$@packetizer.com> References: <5106BFDC.2030706@ericsson.com> <51103D30.2010701@stpeter.im> <548BEEAE-E92F-461F-B06F-ABB40EB9F22C@cisco.com> <041d01ce0427$95b16670$c1143350$@packetizer.com> <047001ce043a$2eee0c50$8cca24f0$@packetizer.com> <071201ce04f5$2c038590$840a90b0$@packetizer.com> Date: Wed, 6 Feb 2013 21:42:39 -0800 Message-ID: From: Tim Bray To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=f46d0445182b32fee504d51be948 X-Gm-Message-State: ALoCoQm8pblxdW/bEi4h/mvnVSOi2nLCFfpGn1+eRhw7TRg1LE3gTylnLpXKEpBFjkh1elAr09Rm Cc: Gonzalo Salgueiro , Murray Kucherawy , Peter Saint-Andre , Brad Fitzpatrick , Salvatore Loreto , "webfinger@ietf.org" Subject: Re: [webfinger] Working Group Last Call for draft-ietf-appsawg-webfinger-09 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, 07 Feb 2013 05:42:42 -0000 --f46d0445182b32fee504d51be948 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Quoting from http://tools.ietf.org/html/rfc3986#section-1.1.3: =93Future specifications and related documentation should use the general term "URI" rather than the more restrictive terms "URL" and "URN"=94 - your favorite Web-architecture pedant, T On Wed, Feb 6, 2013 at 9:37 PM, Paul E. Jones wrote= : > Actually, the revised text was using URI, but I should have used URL to b= e > consistent with other parts of the document. Every place where we refer = to > the WebFinger resource, we say =93URL=94.**** > > ** ** > > The acronym =93URL=94 appears 5 times in the document.**** > > ** ** > > Most other places we use the term =93URI=94 since the =93href=94 can be a= ny URI, > the resource parameter is a URI, etc.**** > > ** ** > > Paul**** > > ** ** > > *From:* Tim Bray [mailto:tbray@textuality.com] > *Sent:* Wednesday, February 06, 2013 11:07 AM > *To:* Paul E. Jones > *Cc:* Salvatore Loreto; Peter Saint-Andre; Murray Kucherawy; > webfinger@ietf.org; Brad Fitzpatrick; Gonzalo Salgueiro > *Subject:* RE: [webfinger] Working Group Last Call for > draft-ietf-appsawg-webfinger-09**** > > ** ** > > Thanks, looks good. I see you used the string "URL"; intentional, or did > you mean URI?**** > > On Feb 5, 2013 11:18 PM, "Paul E. Jones" wrote:**= * > * > > Ok, too tired to argue ;-) You=92re right, but=85 darn, that=92s verbose= .**** > > **** > > It now reads:**** > > **** > > =91A WebFinger client issues a query to the well-known [3] resource > identified by the URI whose path component begins with > =93/.well-known/webfinger=94 and whose query component MUST include the > =93resource=94 parameter exactly once and set to the value of the URI for= which > information is being sought.=92**** > > **** > > To avoid further verbosity, I tried to sidestep the issue by replacing > =93/.well-known/webfinger=94 in the document (not the examples, but just = the > prose). Those changes are:**** > > **** > > Section 6:**** > > =93As with all web resources, access to the WebFinger resource ...=94**** > > **** > > Section 7:**** > > =93When a query is issued to the WebFinger resource, ...=94**** > > =93This WebFinger service URL does not need to point to the well-known > WebFinger location on the hosting service provider server.=94**** > > **** > > Are those other changes OK?**** > > **** > > Paul**** > > **** > > *From:* Tim Bray [mailto:tbray@textuality.com] > *Sent:* Wednesday, February 06, 2013 12:17 AM > *To:* Paul E. Jones > *Cc:* Gonzalo Salgueiro; Salvatore Loreto; Brad Fitzpatrick; Murray > Kucherawy; Peter Saint-Andre; webfinger@ietf.org > *Subject:* Re: [webfinger] Working Group Last Call for > draft-ietf-appsawg-webfinger-09**** > > **** > > These things all live in the context of the WWW, and I think the > nomenclature in http://www.w3.org/TR/webarch/ applies. The Web consists > of Resources, which are identified by URIs, that=92s all there is to it. > > Per webfinger, there should be a resource identified by the URI =93 > https://www.textuality.com/.well-known/webfinger?resource=3Dacct:tbray@te= xtuality.com=94 > On the other hand, =93./well-known/webfinger=94 is not in any sane sense = of the > word a =93resource=94, it=92s a string fragment you=92re using to assembl= e a URI to > identify a particular webfinger resource.**** > > The webfinger spec describes how to construct the URI to identify the > resource by specifying the construction of the path and query components = of > the URI. These are totally conventional web operations and should be > referred to by conventional web terminology. -T**** > > **** > > On Tue, Feb 5, 2013 at 9:05 PM, Paul E. Jones > wrote:**** > > Tim,**** > > **** > > I agree that this is the URI that identifies the resource. Even so, it i= s > the resource.**** > > **** > > Consider,**** > > **** > > =93Tim submitted a suggestion to the co-author Paul=94**** > > **** > > vs.**** > > **** > > =93Time submitted a suggestion to the co-author identified by the given n= ame > Paul=94**** > > **** > > The second form and the first are the same. I am Paul and I am identifie= d > by the given name. Likewise, =93/.well-known/webfinger=94 is often refer= red to > as the resource. It=92s not the resource, but it=92s the name of the res= ource. > **** > > **** > > In section 4.1 we (I think you) introduced text to help clarify what we > mean by a URI parameter. The intent was to not have to have so much > verbosity every time we talk about a URI parameter.**** > > **** > > What Peter suggested to me separately is that we put the name of the > well-known location in quotes. Thus, we have:**** > > **** > > A WebFinger client issues a query to the well-known [3] resource > =93/.well-known/webfinger=94**** > > **** > > I agree we need to be precise, but it makes the text more difficult to > read. What=92s a reasonable compromise?**** > > **** > > The Co-Author Identified by the Given Name Paul ;-)**** > > **** > > *From:* webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] *O= n > Behalf Of *Tim Bray > *Sent:* Monday, February 04, 2013 11:49 PM > *To:* Gonzalo Salgueiro > *Cc:* Salvatore Loreto; Brad Fitzpatrick; Murray Kucherawy; Peter > Saint-Andre; webfinger@ietf.org > *Subject:* Re: [webfinger] Working Group Last Call for > draft-ietf-appsawg-webfinger-09**** > > **** > > One editorial issue, which has no effect on the actual normative effect. > 4.2 says =93A WebFinger client issues a query to the well-known [3] resou= rce > /.well-known/webfinger.=94 > > Um, not really; that isn=92t a resource, that=92s part of a URI. Languag= e > should be along the lines of =93It issues a query to the resource identif= ied > by the URI whose path component begins with =93/.well-known/webfinger?=94= and > whose query component MUST include include the "resource" parameter > exactly....=94 [proceed as before].**** > > I=92d say I hate to be pedantic, but evidence would be against me. In my > defense, publications of the IETF should be careful of their nomenclature > about important things like resources and URIs. -T**** > > **** > > On Mon, Feb 4, 2013 at 8:08 PM, Gonzalo Salgueiro > wrote:**** > > > On Feb 4, 2013, at 5:58 PM, Peter Saint-Andre wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On 2/1/13 10:12 AM, Brad Fitzpatrick wrote: > >> +1 > >> > >> Looks good to me. > > > > Here too. I sent a bunch of editorial feedback to the authors, but I > > see no substantive technical problems here. Kudos to the authors for > > their work on the spec!**** > > Thanks for the extremely detailed review. Upon quick inspection the > suggested edits seem perfectly reasonable. The post WGLC version will > include these. > > Gonzalo**** > > > > > > Peter > > > > - -- > > Peter Saint-Andre > > https://stpeter.im/ > > > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > > > iEYEARECAAYFAlEQPTAACgkQNL8k5A2w/vwi/ACgnjcwR3jTFcbfGebjtiXduydT > > /gEAoK0SpA17y08zxtJB8vNidYqM9Kds > > =3DRV/l > > -----END PGP SIGNATURE----- > > _______________________________________________ > > 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**** > > **** > > **** > --f46d0445182b32fee504d51be948 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Quoting from http://tools.ietf.org/html/rfc3986#section-1.1.3: = =93Future specifications and related documentation should use the general t= erm "URI" rather than the more=A0 restrictive terms "URL&quo= t; and "URN"=94

- your favorite Web-architecture pedant, T


On Wed, Feb 6, 2013 at= 9:37 PM, Paul E. Jones <paulej@packetizer.com> wrote:

Actually, the revised text was using URI, but I should have used URL to = be consistent with other parts of the document.=A0 Every place where we ref= er to the WebFinger resource, we say =93URL=94.

=A0

<= p class=3D"">The acronym =93URL=94 appears = 5 times in the document.

=A0

<= p class=3D"">Most other places we use the t= erm =93URI=94 since the =93href=94 can be any URI, the resource parameter i= s a URI, etc.

=A0

<= p class=3D"">Paul

=A0

<= div style=3D"border-width:medium medium medium 1.5pt;border-style:none none= none solid;border-color:-moz-use-text-color -moz-use-text-color -moz-use-t= ext-color blue;padding:0in 0in 0in 4pt">

From: = Tim Bray [mailto:= tbray@textuality.com]
Sent: Wednesday, February 06, 2013 11:07 AM
To: Paul E. Jo= nes
Cc: Salvatore Loreto; Peter Saint-Andre; Murray Kucherawy; webfinger@ietf.org; Brad Fitzpatrick; Gonzalo Salgueiro
Subject: RE: [webfinger] Working Group Last Call for draft-ietf-apps= awg-webfinger-09

=A0

Thanks, looks good. I see you used t= he string "URL"; intentional, or did you mean URI?<= /p>

On Feb 5, 2013 11:18 PM, "Paul E. Jones" <<= a href=3D"mailto:paulej@packetizer.com" target=3D"_blank">paulej@packetizer= .com> wrote:

Ok, too tired to argue ;-)=A0 You=92re right, but=85 darn= , that=92s verbose.

=A0

<= p class=3D"">It now reads:=

=A0

<= p class=3D"">=91A WebFinger client issues a= query to the well-known [3] resource identified by the URI whose path comp= onent begins with =93/.well-known/webfinger=94 and whose query component MU= ST include the =93resource=94 parameter exactly once and set to the value o= f the URI for which information is being sought.=92

=A0

<= p class=3D"">To avoid further verbosity, I = tried to sidestep the issue by replacing =93/.well-known/webfinger=94 in th= e document (not the examples, but just the prose).=A0 Those changes are:

=A0

<= p class=3D"">Section 6:

=93As with all web resources,= access to the WebFinger resource ...=94

=A0

Section 7:

=93When a query is issu= ed to the WebFinger resource, ...=94

=93This WebFinger service URL= does not need to point to the well-known WebFinger location on the hosting= service provider server.=94

=A0

<= p class=3D"">Are those other changes OK?

=A0

<= p class=3D"">Paul

=A0

<= div style=3D"border-width:medium medium medium 1.5pt;border-style:none none= none solid;border-color:-moz-use-text-color -moz-use-text-color -moz-use-t= ext-color blue;padding:0in 0in 0in 4pt">

From: = Tim Bray [mailto:= tbray@textuality.com]
Sent: Wednesday, February 06, 2013 12:17 AM
To: Paul E. Jo= nes
Cc: Gonzalo Salgueiro; Salvatore Loreto; Brad Fitzpatrick; Mu= rray Kucherawy; Peter Saint-Andre; webfinger@ietf.org
Subject: Re: [webfinger] Working Group Last Call for draft-ietf-apps= awg-webfinger-09

=A0

These thi= ngs all live in the context of the WWW, and I think the nomenclature in http://www.w3.org/= TR/webarch/ applies.=A0 The Web consists of Resources, which are identi= fied by URIs, that=92s all there is to it.

Per webfinger, there should be a resource identified by the URI =93https://www.textuality.com/.well-known= /webfinger?resource=3Dacct:tbray@textuality.com=94 On the other hand, = =93./well-known/webfinger=94 is not in any sane sense of the word a =93reso= urce=94, it=92s a string fragment you=92re using to assemble a URI to ident= ify a particular webfinger resource.

The webfinger spec describes how to construct the URI t= o identify the resource by specifying the construction of the path and quer= y components of the URI. These are totally conventional web operations and = should be referred to by conventional web terminology.=A0 -T<= /p>

=A0

=

On Tue, Feb 5, 2013 at 9:05 PM, Paul E. Jones <paulej@packetizer.com<= /a>> wrote:

Tim,<= u>

=A0

I agree that this is the URI = that identifies the resource.=A0 Even so, it is the resource.=

=A0

<= p class=3D"">Consider,=

=A0

<= p class=3D"">=A0 =93Tim submitted a suggest= ion to the co-author Paul=94

=A0

<= p class=3D"">vs.

=A0

<= p class=3D"">=93Time submitted a suggestion= to the co-author identified by the given name Paul=94=

=A0

<= p class=3D"">The second form and the first = are the same.=A0 I am Paul and I am identified by the given name.=A0 Likewi= se, =93/.well-known/webfinger=94 is often referred to as the resource.=A0 I= t=92s not the resource, but it=92s the name of the resource.<= u>

=A0

<= p class=3D"">In section 4.1 we (I think you= ) introduced text to help clarify what we mean by a URI parameter. =A0The i= ntent was to not have to have so much verbosity every time we talk about a = URI parameter.

=A0

<= p class=3D"">What Peter suggested to me sep= arately is that we put the name of the well-known location in quotes.=A0 Th= us, we have:

=A0

<= p class=3D"">=A0=A0=A0 A WebFinger client i= ssues a query to the well-known [3] resource =93/.well-known/webfinger=94

=A0

<= p class=3D"">I agree we need to be precise,= but it makes the text more difficult to read.=A0 What=92s a reasonable com= promise?

=A0

<= p class=3D"">The Co-Author Identified by th= e Given Name Paul ;-)

=A0

<= div style=3D"border-width:medium medium medium 1.5pt;border-style:none none= none solid;border-color:-moz-use-text-color -moz-use-text-color -moz-use-t= ext-color blue;padding:0in 0in 0in 4pt">

From: = webfinger-b= ounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of Tim Br= ay
Sent: Monday, February 04, 2013 11:49 PM
To: Gonzalo Salgu= eiro
Cc: Salvatore Loreto; Brad Fitzpatrick; Murray Kucherawy; Pe= ter Saint-Andre; we= bfinger@ietf.org
Subject: Re: [webfinger] Working Group Last Call for draft-ietf-apps= awg-webfinger-09

=A0

One editorial issue, which has no effect on the actual normative effect.= =A0 4.2 says =93A WebFinger client issues a query to the well-known [3] res= ource
=A0=A0 /.well-known/webfinger.=94=A0

Um, not really; that isn=92t a= resource, that=92s part of a URI.=A0 Language should be along the lines of= =93It issues a query to the resource identified by the URI whose path comp= onent begins with =93/.well-known/webfinger?=94 and whose query component M= UST include include the "resource" parameter exactly....=94 [proc= eed as before].

I=92d say I hate to be pedantic, but evidence would be = against me.=A0 In my defense, publications of the IETF should be careful of= their nomenclature about important things like resources and URIs.=A0 -T

=A0

=

On Mon, Feb 4, 2013 at 8:08 PM, Gonzalo Salgueiro <gsalguei@cisco.com> wrote:


On Feb 4, 2013, at 5:58= PM, Peter Saint-Andre <stpeter@stpeter.im> wrote:

> -----BEGIN PGP SIGNED= MESSAGE-----
> Hash: SHA1
>
> On 2/1/13 10:12 AM, Brad Fitzpatrick wrote:=
>> +1
>>
>> Looks good to me.
>
> H= ere too. I sent a bunch of editorial feedback to the authors, but I
> see no substantive technical problems here. Kudos to the authors for> their work on the spec!

Thanks = for the extremely detailed review. =A0Upon quick inspection the suggested e= dits seem perfectly reasonable. =A0The post WGLC version will include these= .

Gonzalo

=


>
> Peter
>
> - --
>= Peter Saint-Andre
> https://stpeter.im/
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/M= acGPG2 v2.0.18 (Darwin)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net= /
>
> iEYEARECAAYFAlEQPTAACgkQNL8k5A2w/vwi/ACgnjcwR3jTFcbfGebjtiXduy= dT
> /gEAoK0SpA17y08zxtJB8vNidYqM9Kds
> =3DRV/l
> -----EN= D PGP SIGNATURE-----
> ______________________________________________= _
> webfinger mailing list
> webfinger@ietf.org
> https://www.ietf.org/mai= lman/listinfo/webfinger
>

_______________________________________________
webfinger ma= iling list
webfi= nger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger=

=A0

=A0


=
--f46d0445182b32fee504d51be948-- From paulej@packetizer.com Wed Feb 6 21:57:16 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 EAC1521F8438 for ; Wed, 6 Feb 2013 21:57:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHq9pySzOCB5 for ; Wed, 6 Feb 2013 21:57:16 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 22BDE21F8168 for ; Wed, 6 Feb 2013 21:57:15 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r175vDrl023798 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Feb 2013 00:57:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1360216633; bh=4Dswx29/hnWy0IGDPeHX0JkVSudyBGUOO8Q2sR4EhTk=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding; b=uDH9ftH7QukloUuj121Rl6HFN41NgLEZpwd8so+Kny9Qgbmn/MpOdEjWSOYuuLPcC 0UlnuRV3Hewt7a6f5RphSX8BoSXfKGJuicwlPlt5EON9qbhHnnOoZ9zUJAZaVe+CPq yx+BFw9eC0N02+yHM69e7UgtV/KP3XrKsh705ZtE= From: "Paul E. Jones" To: , "'Dave Cridland'" , "'Mark Nottingham'" Date: Thu, 7 Feb 2013 00:57:21 -0500 Message-ID: <072501ce04f7$feee5af0$fccb10d0$@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: Ac4E9kTALtGQKKN2QLeF5VT1+OJZLQ== Content-Language: en-us Subject: [webfinger] Media type for 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, 07 Feb 2013 05:57:17 -0000 Folks, Most of the comments received have been editorial. I've tried to capture all of them, though there is the possibility one slips through. None seem like showstoppers. However, one comment that I've not taken action on is defining a media type for WebFinger. There are split views on this. Some are arguing we need something and others say we don't. Some say it might be helpful if present, but not everyone agrees. Personally, I'm in the camp that we do not need anything more than application/json. A query to a WebFinger resource means one would get a WF response and the application type is really not so important. It is important to know that it's application/json vs. XML or plain text or other, but to introduce something like application/jrd+json or some such seems like overkill to me. I've not seen this done for the gazillion other web services that use JSON. So, is there truly a need to have an dedicated type? If so, what should be the name of this type? And is WF going to be the first of a bunch of spec that create a bunch of JSON media types like there were for +xml? I prefer application/json, unless there is a technical reason someone can bring to my attention to show why this is a bad idea. Paul From paulej@packetizer.com Wed Feb 6 22:10: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 05E4321F85CC for ; Wed, 6 Feb 2013 22:10:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPtvGImlRs3g for ; Wed, 6 Feb 2013 22:10:29 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id DDA3B21F85B2 for ; Wed, 6 Feb 2013 22:10:28 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r176ANVS025421 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Feb 2013 01:10:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1360217424; bh=g+XJvjhxfLnrirg1pnaWUVPPhLluMkAlt9emavfVnoo=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=Z2sv5cr1WKJQY3ZY7OuQXKE/AJiYDTBMa2bdtOUyUz0PPECp8X2s5VnCgMWjFNasr AFVaYuRy1uqB62sWZ1pU4nmSWieLGDV+bpc9AZ9172Ia3SKtMjcWWa+lUwAtIkJUQD AhPlOXx4DfkCmAxJ+A9hByYWdm+dQGJxKo9Wn3sg= From: "Paul E. Jones" To: "'Tim Bray'" References: <5106BFDC.2030706@ericsson.com> <51103D30.2010701@stpeter.im> <548BEEAE-E92F-461F-B06F-ABB40EB9F22C@cisco.com> <041d01ce0427$95b16670$c1143350$@packetizer.com> <047001ce043a$2eee0c50$8cca24f0$@packetizer.com> <071201ce04f5$2c038590$840a90b0$@packetizer.com> In-Reply-To: Date: Thu, 7 Feb 2013 01:10:31 -0500 Message-ID: <072a01ce04f9$d5e7d030$81b77090$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_072B_01CE04CF.ED143930" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE1BCY4ftSPh+1CSwbfjBRSkBwUGQKEsM7KArFjXBkCX9tzEAF0ZkifAfmawQgA8QJQmwKpRsb2AfpQevICnlahwgJP0EuemPOzyRA= Content-Language: en-us Cc: 'Gonzalo Salgueiro' , 'Murray Kucherawy' , 'Peter Saint-Andre' , 'Brad Fitzpatrick' , 'Salvatore Loreto' , webfinger@ietf.org Subject: Re: [webfinger] Working Group Last Call for draft-ietf-appsawg-webfinger-09 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, 07 Feb 2013 06:10:49 -0000 This is a multipart message in MIME format. ------=_NextPart_000_072B_01CE04CF.ED143930 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I'll note that says "should" and not even normatively. In every instance where we use URL, it is a locator. Unless we're striking the term URL entirely from the IETF vocabulary, I think it's more appropriate to use URL where we do. I'm perplexed by this sentence, actually. It reads like "we've invented cars and trucks, both of which are called automobiles. However, you should never refer to cars as cars or trucks as trucks. Rather, you should only speak of automobiles, even if you're referring only to a truck." Why? I must be missing something. Your favorite co-author identified by a name whose given component is Paul From: Tim Bray [mailto:tbray@textuality.com] Sent: Thursday, February 07, 2013 12:43 AM To: Paul E. Jones Cc: Salvatore Loreto; Peter Saint-Andre; Murray Kucherawy; webfinger@ietf.org; Brad Fitzpatrick; Gonzalo Salgueiro Subject: Re: [webfinger] Working Group Last Call for draft-ietf-appsawg-webfinger-09 Quoting from http://tools.ietf.org/html/rfc3986#section-1.1.3: "Future specifications and related documentation should use the general term "URI" rather than the more restrictive terms "URL" and "URN"" - your favorite Web-architecture pedant, T On Wed, Feb 6, 2013 at 9:37 PM, Paul E. Jones wrote: Actually, the revised text was using URI, but I should have used URL to be consistent with other parts of the document. Every place where we refer to the WebFinger resource, we say "URL". The acronym "URL" appears 5 times in the document. Most other places we use the term "URI" since the "href" can be any URI, the resource parameter is a URI, etc. Paul From: Tim Bray [mailto:tbray@textuality.com] Sent: Wednesday, February 06, 2013 11:07 AM To: Paul E. Jones Cc: Salvatore Loreto; Peter Saint-Andre; Murray Kucherawy; webfinger@ietf.org; Brad Fitzpatrick; Gonzalo Salgueiro Subject: RE: [webfinger] Working Group Last Call for draft-ietf-appsawg-webfinger-09 Thanks, looks good. I see you used the string "URL"; intentional, or did you mean URI? On Feb 5, 2013 11:18 PM, "Paul E. Jones" wrote: Ok, too tired to argue ;-) You're right, but. darn, that's verbose. It now reads: 'A WebFinger client issues a query to the well-known [3] resource identified by the URI whose path component begins with "/.well-known/webfinger" and whose query component MUST include the "resource" parameter exactly once and set to the value of the URI for which information is being sought.' To avoid further verbosity, I tried to sidestep the issue by replacing "/.well-known/webfinger" in the document (not the examples, but just the prose). Those changes are: Section 6: "As with all web resources, access to the WebFinger resource ..." Section 7: "When a query is issued to the WebFinger resource, ..." "This WebFinger service URL does not need to point to the well-known WebFinger location on the hosting service provider server." Are those other changes OK? Paul From: Tim Bray [mailto:tbray@textuality.com] Sent: Wednesday, February 06, 2013 12:17 AM To: Paul E. Jones Cc: Gonzalo Salgueiro; Salvatore Loreto; Brad Fitzpatrick; Murray Kucherawy; Peter Saint-Andre; webfinger@ietf.org Subject: Re: [webfinger] Working Group Last Call for draft-ietf-appsawg-webfinger-09 These things all live in the context of the WWW, and I think the nomenclature in http://www.w3.org/TR/webarch/ applies. The Web consists of Resources, which are identified by URIs, that's all there is to it. Per webfinger, there should be a resource identified by the URI "https://www.textuality.com/.well-known/webfinger?resource=acct:tbray@textua lity.com" On the other hand, "./well-known/webfinger" is not in any sane sense of the word a "resource", it's a string fragment you're using to assemble a URI to identify a particular webfinger resource. The webfinger spec describes how to construct the URI to identify the resource by specifying the construction of the path and query components of the URI. These are totally conventional web operations and should be referred to by conventional web terminology. -T On Tue, Feb 5, 2013 at 9:05 PM, Paul E. Jones wrote: Tim, I agree that this is the URI that identifies the resource. Even so, it is the resource. Consider, "Tim submitted a suggestion to the co-author Paul" vs. "Time submitted a suggestion to the co-author identified by the given name Paul" The second form and the first are the same. I am Paul and I am identified by the given name. Likewise, "/.well-known/webfinger" is often referred to as the resource. It's not the resource, but it's the name of the resource. In section 4.1 we (I think you) introduced text to help clarify what we mean by a URI parameter. The intent was to not have to have so much verbosity every time we talk about a URI parameter. What Peter suggested to me separately is that we put the name of the well-known location in quotes. Thus, we have: A WebFinger client issues a query to the well-known [3] resource "/.well-known/webfinger" I agree we need to be precise, but it makes the text more difficult to read. What's a reasonable compromise? The Co-Author Identified by the Given Name Paul ;-) From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of Tim Bray Sent: Monday, February 04, 2013 11:49 PM To: Gonzalo Salgueiro Cc: Salvatore Loreto; Brad Fitzpatrick; Murray Kucherawy; Peter Saint-Andre; webfinger@ietf.org Subject: Re: [webfinger] Working Group Last Call for draft-ietf-appsawg-webfinger-09 One editorial issue, which has no effect on the actual normative effect. 4.2 says "A WebFinger client issues a query to the well-known [3] resource /.well-known/webfinger." Um, not really; that isn't a resource, that's part of a URI. Language should be along the lines of "It issues a query to the resource identified by the URI whose path component begins with "/.well-known/webfinger?" and whose query component MUST include include the "resource" parameter exactly...." [proceed as before]. I'd say I hate to be pedantic, but evidence would be against me. In my defense, publications of the IETF should be careful of their nomenclature about important things like resources and URIs. -T On Mon, Feb 4, 2013 at 8:08 PM, Gonzalo Salgueiro wrote: On Feb 4, 2013, at 5:58 PM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 2/1/13 10:12 AM, Brad Fitzpatrick wrote: >> +1 >> >> Looks good to me. > > Here too. I sent a bunch of editorial feedback to the authors, but I > see no substantive technical problems here. Kudos to the authors for > their work on the spec! Thanks for the extremely detailed review. Upon quick inspection the suggested edits seem perfectly reasonable. The post WGLC version will include these. Gonzalo > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iEYEARECAAYFAlEQPTAACgkQNL8k5A2w/vwi/ACgnjcwR3jTFcbfGebjtiXduydT > /gEAoK0SpA17y08zxtJB8vNidYqM9Kds > =RV/l > -----END PGP SIGNATURE----- > _______________________________________________ > 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_072B_01CE04CF.ED143930 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ll note that says “should” and not even = normatively.

 

In every instance where we use URL, it is a locator.  Unless = we’re striking the term URL entirely from the IETF vocabulary, I = think it’s more appropriate to use URL where we = do.

 

I’m perplexed by this sentence, actually.  It reads like = “we’ve invented cars and trucks, both of which are called = automobiles.  However, you should never refer to cars as cars or = trucks as trucks.  Rather, you should only speak of automobiles, = even if you’re referring only to a = truck.”

 

Why?  I must be missing something.

 

Your favorite co-author identified by a name whose given component is = Paul

 

From:= = Tim Bray [mailto:tbray@textuality.com]
Sent: Thursday, = February 07, 2013 12:43 AM
To: Paul E. Jones
Cc: = Salvatore Loreto; Peter Saint-Andre; Murray Kucherawy; = webfinger@ietf.org; Brad Fitzpatrick; Gonzalo = Salgueiro
Subject: Re: [webfinger] Working Group Last Call for = draft-ietf-appsawg-webfinger-09

 

Quoting from http://tools.ie= tf.org/html/rfc3986#section-1.1.3: “Future specifications and = related documentation should use the general term "URI" rather = than the more  restrictive terms "URL" and = "URN"”

- your = favorite Web-architecture pedant, T

 

On Wed, Feb 6, 2013 at 9:37 PM, Paul E. Jones <paulej@packetizer.com> = wrote:

Actually, the revised text was using URI, but I should have used URL = to be consistent with other parts of the document.  Every place = where we refer to the WebFinger resource, we say = “URL”.

 

The acronym “URL” appears 5 times in the = document.

 

Most other places we use the term “URI” since the = “href” can be any URI, the resource parameter is a URI, = etc.

 

Paul

 

From:= = Tim Bray [mailto:tbray@textuality.com]
Sent: Wednesday, = February 06, 2013 11:07 AM
To: Paul E. Jones
Cc: = Salvatore Loreto; Peter Saint-Andre; Murray Kucherawy; webfinger@ietf.org; Brad Fitzpatrick; Gonzalo = Salgueiro
Subject: RE: [webfinger] Working Group Last Call for = draft-ietf-appsawg-webfinger-09

 <= /o:p>

Thanks, looks good. I see you used the string = "URL"; intentional, or did you mean URI?

On Feb 5, = 2013 11:18 PM, "Paul E. Jones" <paulej@packetizer.com> = wrote:

Ok, too tired to argue ;-)  You’re right, but… darn, = that’s verbose.

 

It now reads:

 

‘A WebFinger client issues a query to the well-known [3] = resource identified by the URI whose path component begins with = “/.well-known/webfinger” and whose query component MUST = include the “resource” parameter exactly once and set to the = value of the URI for which information is being = sought.’

 

To avoid further verbosity, I tried to sidestep the issue by = replacing “/.well-known/webfinger” in the document (not the = examples, but just the prose).  Those changes = are:

 

Section 6:

“As with all web resources, access to the WebFinger resource = ...”

 

Section 7:

“When a query is issued to the WebFinger resource, = ...”

“This WebFinger service URL does not need to point to the = well-known WebFinger location on the hosting service provider = server.”

 

Are those other changes OK?

 

Paul

 

From:= = Tim Bray [mailto:tbray@textuality.com]
Sent: Wednesday, = February 06, 2013 12:17 AM
To: Paul E. Jones
Cc: = Gonzalo Salgueiro; Salvatore Loreto; Brad Fitzpatrick; Murray Kucherawy; = Peter Saint-Andre; webfinger@ietf.org
Subject: Re: = [webfinger] Working Group Last Call for = draft-ietf-appsawg-webfinger-09

 <= /o:p>

These things all = live in the context of the WWW, and I think the nomenclature in http://www.w3.org/TR/webarch/ applies.  The = Web consists of Resources, which are identified by URIs, that’s = all there is to it.

Per webfinger, there should be a resource = identified by the URI “https://www.textuality.com/.well-known/webfinger?resour= ce=3Dacct:tbray@textuality.com” On the other hand, = “./well-known/webfinger” is not in any sane sense of the = word a “resource”, it’s a string fragment you’re = using to assemble a URI to identify a particular webfinger = resource.

The = webfinger spec describes how to construct the URI to identify the = resource by specifying the construction of the path and query components = of the URI. These are totally conventional web operations and should be = referred to by conventional web terminology.  = -T

 <= /p>

On Tue, Feb = 5, 2013 at 9:05 PM, Paul E. Jones <paulej@packetizer.com> = wrote:

Tim,

 

I agree that this is the URI that identifies the resource.  Even = so, it is the resource.

 

Consider,

 

  “Tim submitted a suggestion to the co-author = Paul”

 

vs.

 

“Time submitted a suggestion to the co-author identified by the = given name Paul”

 

The second form and the first are the same.  I am Paul and I am = identified by the given name.  Likewise, = “/.well-known/webfinger” is often referred to as the = resource.  It’s not the resource, but it’s the name of = the resource.

 

In section 4.1 we (I think you) introduced text to help clarify what = we mean by a URI parameter.  The intent was to not have to have so = much verbosity every time we talk about a URI = parameter.

 

What Peter suggested to me separately is that we put the name of the = well-known location in quotes.  Thus, we = have:

 

    A WebFinger client issues a query to the = well-known [3] resource = “/.well-known/webfinger”

 

I agree we need to be precise, but it makes the text more difficult = to read.  What’s a reasonable = compromise?

 

The Co-Author Identified by the Given Name Paul = ;-)

 

From:= = webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of = Tim Bray
Sent: Monday, February 04, 2013 11:49 = PM
To: Gonzalo Salgueiro
Cc: Salvatore Loreto; Brad = Fitzpatrick; Murray Kucherawy; Peter Saint-Andre; webfinger@ietf.org
Subject: Re: = [webfinger] Working Group Last Call for = draft-ietf-appsawg-webfinger-09

 <= /o:p>

One editorial = issue, which has no effect on the actual normative effect.  4.2 = says “A WebFinger client issues a query to the well-known [3] = resource
   /.well-known/webfinger.”  =

Um, not really; that isn’t a resource, that’s part = of a URI.  Language should be along the lines of “It issues a = query to the resource identified by the URI whose path component begins = with “/.well-known/webfinger?” and whose query component = MUST include include the "resource" parameter = exactly....” [proceed as before].

I’d = say I hate to be pedantic, but evidence would be against me.  In my = defense, publications of the IETF should be careful of their = nomenclature about important things like resources and URIs.  = -T

 <= /p>

On Mon, Feb = 4, 2013 at 8:08 PM, Gonzalo Salgueiro <gsalguei@cisco.com> = wrote:


On Feb 4, = 2013, at 5:58 PM, Peter Saint-Andre <stpeter@stpeter.im> wrote:

> = -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On = 2/1/13 10:12 AM, Brad Fitzpatrick wrote:
>> = +1
>>
>> Looks good to me.
>
> Here too. I = sent a bunch of editorial feedback to the authors, but I
> see no = substantive technical problems here. Kudos to the authors for
> = their work on the spec!

Thanks for = the extremely detailed review.  Upon quick inspection the suggested = edits seem perfectly reasonable.  The post WGLC version will = include these.

Gonzalo


>
= > Peter
>
> - --
> Peter Saint-Andre
> https://stpeter.im/
>
>
> = -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.18 = (Darwin)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> = iEYEARECAAYFAlEQPTAACgkQNL8k5A2w/vwi/ACgnjcwR3jTFcbfGebjtiXduydT
> = /gEAoK0SpA17y08zxtJB8vNidYqM9Kds
> =3DRV/l
> -----END PGP = SIGNATURE-----
> = _______________________________________________
> 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

 <= /o:p>

 <= /o:p>

 

------=_NextPart_000_072B_01CE04CF.ED143930-- From tbray@textuality.com Wed Feb 6 22:20:40 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 E053821F85CC for ; Wed, 6 Feb 2013 22:20:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.416 X-Spam-Level: X-Spam-Status: No, score=-3.416 tagged_above=-999 required=5 tests=[AWL=-0.440, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FCLC0KOzqNgg for ; Wed, 6 Feb 2013 22:20:39 -0800 (PST) Received: from mail-ob0-f170.google.com (mail-ob0-f170.google.com [209.85.214.170]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF4321F850C for ; Wed, 6 Feb 2013 22:20:38 -0800 (PST) Received: by mail-ob0-f170.google.com with SMTP id wc20so2382939obb.15 for ; Wed, 06 Feb 2013 22:20:38 -0800 (PST) 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=egcwpdu3z7iM+Xw7KHMWIucn9rwOMdNfwKakqoiiaI0=; b=ThiWTS8zmIh9Qn6dkF3/LMqlxy14b+rbrvq/THnodQpp/8P98VG+tF6vW4tPDnF2y3 Dm+NSZnTMZ/QHNb5mY+VGa5PdDeBAP909NXHK/R/rT2XYKkuXkCMqzZMxtjzOhoYjv4Y O9e28f43hV2gcZ9p2ABY6y7dPl5Z0hJ/s1v7R2EuvDkCQEe+Z3SMEkN9sSuUS1OJMtfC gYGBB1JnrKVnPY/CisIzANCIPBaVeNzmEV7QttC3xef74Uix4iMi7E3XXGq5duPYMO/j mJOAQHD9eJANaA6XEpRXhyr17q1YTNPq+lkO9HVMm7fLEHGj5fjq8k15uCGyqqqN2SAl DuZA== MIME-Version: 1.0 X-Received: by 10.60.29.193 with SMTP id m1mr117761oeh.36.1360218038578; Wed, 06 Feb 2013 22:20:38 -0800 (PST) Received: by 10.76.173.38 with HTTP; Wed, 6 Feb 2013 22:20:38 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: <072a01ce04f9$d5e7d030$81b77090$@packetizer.com> References: <5106BFDC.2030706@ericsson.com> <51103D30.2010701@stpeter.im> <548BEEAE-E92F-461F-B06F-ABB40EB9F22C@cisco.com> <041d01ce0427$95b16670$c1143350$@packetizer.com> <047001ce043a$2eee0c50$8cca24f0$@packetizer.com> <071201ce04f5$2c038590$840a90b0$@packetizer.com> <072a01ce04f9$d5e7d030$81b77090$@packetizer.com> Date: Wed, 6 Feb 2013 22:20:38 -0800 Message-ID: From: Tim Bray To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=e89a8ff242a101ad6f04d51c71b7 X-Gm-Message-State: ALoCoQkGs38EEiUXduNlfk9m32ba9YUQIDxVd6Mw4BM0kZvIi0sk4S1N236I6gYY+/yz/9P5HDDP Cc: Gonzalo Salgueiro , Murray Kucherawy , Peter Saint-Andre , Brad Fitzpatrick , Salvatore Loreto , "webfinger@ietf.org" Subject: Re: [webfinger] Working Group Last Call for draft-ietf-appsawg-webfinger-09 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, 07 Feb 2013 06:20:41 -0000 --e89a8ff242a101ad6f04d51c71b7 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable If the WG is OK with ignoring the perfectly-clear terminology guidance from RFC3986, I=92m certainly not going to lie down in the road over it. -T On Wed, Feb 6, 2013 at 10:10 PM, Paul E. Jones wrote= : > I=92ll note that says =93should=94 and not even normatively.**** > > ** ** > > In every instance where we use URL, it is a locator. Unless we=92re > striking the term URL entirely from the IETF vocabulary, I think it=92s m= ore > appropriate to use URL where we do.**** > > ** ** > > I=92m perplexed by this sentence, actually. It reads like =93we=92ve inv= ented > cars and trucks, both of which are called automobiles. However, you shou= ld > never refer to cars as cars or trucks as trucks. Rather, you should only > speak of automobiles, even if you=92re referring only to a truck.=94**** > > ** ** > > Why? I must be missing something.**** > > ** ** > > Your favorite co-author identified by a name whose given component is Pau= l > **** > > ** ** > > *From:* Tim Bray [mailto:tbray@textuality.com] > *Sent:* Thursday, February 07, 2013 12:43 AM > > *To:* Paul E. Jones > *Cc:* Salvatore Loreto; Peter Saint-Andre; Murray Kucherawy; > webfinger@ietf.org; Brad Fitzpatrick; Gonzalo Salgueiro > *Subject:* Re: [webfinger] Working Group Last Call for > draft-ietf-appsawg-webfinger-09**** > > ** ** > > Quoting from http://tools.ietf.org/html/rfc3986#section-1.1.3: =93Future > specifications and related documentation should use the general term "URI= " > rather than the more restrictive terms "URL" and "URN"=94**** > > - your favorite Web-architecture pedant, T**** > > ** ** > > On Wed, Feb 6, 2013 at 9:37 PM, Paul E. Jones > wrote:**** > > Actually, the revised text was using URI, but I should have used URL to b= e > consistent with other parts of the document. Every place where we refer = to > the WebFinger resource, we say =93URL=94.**** > > **** > > The acronym =93URL=94 appears 5 times in the document.**** > > **** > > Most other places we use the term =93URI=94 since the =93href=94 can be a= ny URI, > the resource parameter is a URI, etc.**** > > **** > > Paul**** > > **** > > *From:* Tim Bray [mailto:tbray@textuality.com] > *Sent:* Wednesday, February 06, 2013 11:07 AM > *To:* Paul E. Jones > *Cc:* Salvatore Loreto; Peter Saint-Andre; Murray Kucherawy; > webfinger@ietf.org; Brad Fitzpatrick; Gonzalo Salgueiro > *Subject:* RE: [webfinger] Working Group Last Call for > draft-ietf-appsawg-webfinger-09**** > > **** > > Thanks, looks good. I see you used the string "URL"; intentional, or did > you mean URI?**** > > On Feb 5, 2013 11:18 PM, "Paul E. Jones" wrote:**= * > * > > Ok, too tired to argue ;-) You=92re right, but=85 darn, that=92s verbose= .**** > > **** > > It now reads:**** > > **** > > =91A WebFinger client issues a query to the well-known [3] resource > identified by the URI whose path component begins with > =93/.well-known/webfinger=94 and whose query component MUST include the > =93resource=94 parameter exactly once and set to the value of the URI for= which > information is being sought.=92**** > > **** > > To avoid further verbosity, I tried to sidestep the issue by replacing > =93/.well-known/webfinger=94 in the document (not the examples, but just = the > prose). Those changes are:**** > > **** > > Section 6:**** > > =93As with all web resources, access to the WebFinger resource ...=94**** > > **** > > Section 7:**** > > =93When a query is issued to the WebFinger resource, ...=94**** > > =93This WebFinger service URL does not need to point to the well-known > WebFinger location on the hosting service provider server.=94**** > > **** > > Are those other changes OK?**** > > **** > > Paul**** > > **** > > *From:* Tim Bray [mailto:tbray@textuality.com] > *Sent:* Wednesday, February 06, 2013 12:17 AM > *To:* Paul E. Jones > *Cc:* Gonzalo Salgueiro; Salvatore Loreto; Brad Fitzpatrick; Murray > Kucherawy; Peter Saint-Andre; webfinger@ietf.org > *Subject:* Re: [webfinger] Working Group Last Call for > draft-ietf-appsawg-webfinger-09**** > > **** > > These things all live in the context of the WWW, and I think the > nomenclature in http://www.w3.org/TR/webarch/ applies. The Web consists > of Resources, which are identified by URIs, that=92s all there is to it. > > Per webfinger, there should be a resource identified by the URI =93 > https://www.textuality.com/.well-known/webfinger?resource=3Dacct:tbray@te= xtuality.com=94 > On the other hand, =93./well-known/webfinger=94 is not in any sane sense = of the > word a =93resource=94, it=92s a string fragment you=92re using to assembl= e a URI to > identify a particular webfinger resource.**** > > The webfinger spec describes how to construct the URI to identify the > resource by specifying the construction of the path and query components = of > the URI. These are totally conventional web operations and should be > referred to by conventional web terminology. -T**** > > **** > > On Tue, Feb 5, 2013 at 9:05 PM, Paul E. Jones > wrote:**** > > Tim,**** > > **** > > I agree that this is the URI that identifies the resource. Even so, it i= s > the resource.**** > > **** > > Consider,**** > > **** > > =93Tim submitted a suggestion to the co-author Paul=94**** > > **** > > vs.**** > > **** > > =93Time submitted a suggestion to the co-author identified by the given n= ame > Paul=94**** > > **** > > The second form and the first are the same. I am Paul and I am identifie= d > by the given name. Likewise, =93/.well-known/webfinger=94 is often refer= red to > as the resource. It=92s not the resource, but it=92s the name of the res= ource. > **** > > **** > > In section 4.1 we (I think you) introduced text to help clarify what we > mean by a URI parameter. The intent was to not have to have so much > verbosity every time we talk about a URI parameter.**** > > **** > > What Peter suggested to me separately is that we put the name of the > well-known location in quotes. Thus, we have:**** > > **** > > A WebFinger client issues a query to the well-known [3] resource > =93/.well-known/webfinger=94**** > > **** > > I agree we need to be precise, but it makes the text more difficult to > read. What=92s a reasonable compromise?**** > > **** > > The Co-Author Identified by the Given Name Paul ;-)**** > > **** > > *From:* webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] *O= n > Behalf Of *Tim Bray > *Sent:* Monday, February 04, 2013 11:49 PM > *To:* Gonzalo Salgueiro > *Cc:* Salvatore Loreto; Brad Fitzpatrick; Murray Kucherawy; Peter > Saint-Andre; webfinger@ietf.org > *Subject:* Re: [webfinger] Working Group Last Call for > draft-ietf-appsawg-webfinger-09**** > > **** > > One editorial issue, which has no effect on the actual normative effect. > 4.2 says =93A WebFinger client issues a query to the well-known [3] resou= rce > /.well-known/webfinger.=94 > > Um, not really; that isn=92t a resource, that=92s part of a URI. Languag= e > should be along the lines of =93It issues a query to the resource identif= ied > by the URI whose path component begins with =93/.well-known/webfinger?=94= and > whose query component MUST include include the "resource" parameter > exactly....=94 [proceed as before].**** > > I=92d say I hate to be pedantic, but evidence would be against me. In my > defense, publications of the IETF should be careful of their nomenclature > about important things like resources and URIs. -T**** > > **** > > On Mon, Feb 4, 2013 at 8:08 PM, Gonzalo Salgueiro > wrote:**** > > > On Feb 4, 2013, at 5:58 PM, Peter Saint-Andre wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On 2/1/13 10:12 AM, Brad Fitzpatrick wrote: > >> +1 > >> > >> Looks good to me. > > > > Here too. I sent a bunch of editorial feedback to the authors, but I > > see no substantive technical problems here. Kudos to the authors for > > their work on the spec!**** > > Thanks for the extremely detailed review. Upon quick inspection the > suggested edits seem perfectly reasonable. The post WGLC version will > include these. > > Gonzalo**** > > > > > > Peter > > > > - -- > > Peter Saint-Andre > > https://stpeter.im/ > > > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > > > iEYEARECAAYFAlEQPTAACgkQNL8k5A2w/vwi/ACgnjcwR3jTFcbfGebjtiXduydT > > /gEAoK0SpA17y08zxtJB8vNidYqM9Kds > > =3DRV/l > > -----END PGP SIGNATURE----- > > _______________________________________________ > > 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**** > > **** > > **** > > ** ** > --e89a8ff242a101ad6f04d51c71b7 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
If the WG is OK with ignoring the perfectly-clear ter= minology guidance from RFC3986, I=92m certainly not going to lie down in th= e road over it.

-T


On Wed, Feb 6, 2013 at 10:10 PM, Paul E.= Jones <paulej@packetizer.com> wrote:

I=92ll note that says =93should=94 and not e= ven normatively.

=A0<= /p>

In every instance wher= e we use URL, it is a locator.=A0 Unless we=92re striking the term URL enti= rely from the IETF vocabulary, I think it=92s more appropriate to use URL w= here we do.

=A0<= /p>

I=92m perplexed by thi= s sentence, actually.=A0 It reads like =93we=92ve invented cars and trucks,= both of which are called automobiles.=A0 However, you should never refer t= o cars as cars or trucks as trucks.=A0 Rather, you should only speak of aut= omobiles, even if you=92re referring only to a truck.=94

=A0<= /p>

Why?=A0 I must be miss= ing something.

=A0<= /p>

Your favorite co-autho= r identified by a name whose given component is Paul

=A0<= /p>

From: Tim Bray [mailto:tbray@textuality.com]
Sent: Thursday, February 07, 2013 12:43 AM


To: Paul E. Jones
Cc: Salvatore Loreto; Peter Saint= -Andre; Murray Kucherawy; webfinger@ietf.org; Brad Fitzpatrick; Gonzalo Salgueiro
Subject: Re: [webfinger] Working Group = Last Call for draft-ietf-appsawg-webfinger-09

<= /p>

=A0<= /u>

Quoting fro= m http://tools.ietf.org/html/rfc3986#section-1.1.3: =93Future speci= fications and related documentation should use the general term "URI&q= uot; rather than the more=A0 restrictive terms "URL" and "UR= N"=94

- your favorite Web-architecture pedant, T<= /u>

=A0

On Wed, Feb 6, 201= 3 at 9:37 PM, Paul E. Jones <paulej@packetizer.com> wrote:

Actually, the r= evised text was using URI, but I should have used URL to be consistent with= other parts of the document.=A0 Every place where we refer to the WebFinge= r resource, we say =93URL=94.

=A0<= /p>

The acronym =93URL=94 = appears 5 times in the document.

=A0<= /p>

Most other places we u= se the term =93URI=94 since the =93href=94 can be any URI, the resource par= ameter is a URI, etc.

=A0<= /p>

Paul<= /u>

=A0<= /p>

From: Tim Bray [mai= lto:tbray@textual= ity.com]
Sent: Wednesday, February 06, 2013 11:07 AM
To: Paul E. Jo= nes
Cc: Salvatore Loreto; Peter Saint-Andre; Murray Kucherawy; webfinger@ietf.org; Brad Fitzpatrick; Gonzalo Salgueiro
Subject: RE: [webfinger] Working Group Last Call for draft-ietf-apps= awg-webfinger-09

=A0

Thanks, looks good. I see you used the s= tring "URL"; intentional, or did you mean URI?

On Feb 5, 2013 11:18 PM, "Paul E. Jones&qu= ot; <paulej@p= acketizer.com> wrote:

Ok, too tired to argue ;-)=A0 You=92re right, bu= t=85 darn, that=92s verbose.

=A0

It now reads:

=A0

=91A WebFinger client iss= ues a query to the well-known [3] resource identified by the URI whose path= component begins with =93/.well-known/webfinger=94 and whose query compone= nt MUST include the =93resource=94 parameter exactly once and set to the va= lue of the URI for which information is being sought.=92

=A0<= /p>

To avoid further verbo= sity, I tried to sidestep the issue by replacing =93/.well-known/webfinger= =94 in the document (not the examples, but just the prose).=A0 Those change= s are:

=A0<= /p>

Section 6:

=93As with all web resour= ces, access to the WebFinger resource ...=94

=A0

Section 7:

=93When a query is issued= to the WebFinger resource, ...=94

=93This WebFinger service URL does not need to p= oint to the well-known WebFinger location on the hosting service provider s= erver.=94

=A0<= /p>

Are those other change= s OK?

=A0<= /p>

Paul<= /u>

=A0<= /p>

From: Tim Bray [mai= lto:tbray@textual= ity.com]
Sent: Wednesday, February 06, 2013 12:17 AM
To: Paul E. Jo= nes
Cc: Gonzalo Salgueiro; Salvatore Loreto; Brad Fitzpatrick; Mu= rray Kucherawy; Peter Saint-Andre; webfinger@ietf.org
Subject: Re: [webfinger] Working Group Last Call for draft-ietf-apps= awg-webfinger-09

=A0

These things all live in the context of the WWW, and I think the nomenclatu= re in http://ww= w.w3.org/TR/webarch/ applies.=A0 The Web consists of Resources, which a= re identified by URIs, that=92s all there is to it.

Per webfinger, there should be a resource identified by the URI =93https://www.textuality.com/.well-known= /webfinger?resource=3Dacct:tbray@textuality.com=94 On the other hand, = =93./well-known/webfinger=94 is not in any sane sense of the word a =93reso= urce=94, it=92s a string fragment you=92re using to assemble a URI to ident= ify a particular webfinger resource.

The webfinger spec describes how to construct = the URI to identify the resource by specifying the construction of the path= and query components of the URI. These are totally conventional web operat= ions and should be referred to by conventional web terminology.=A0 -T

=A0=

On Tue, Feb 5, 2013 at 9:05 PM, Paul= E. Jones <pa= ulej@packetizer.com> wrote:

Tim,<= /u>

=A0<= u>

I agree that this is the = URI that identifies the resource.=A0 Even so, it is the resource.=

=A0<= /p>

Consider,

=A0<= /p>

=A0 =93Tim submitted a= suggestion to the co-author Paul=94

=A0<= /p>

vs.

=A0<= /p>

=93Time submitted a su= ggestion to the co-author identified by the given name Paul=94

=A0<= /p>

The second form and th= e first are the same.=A0 I am Paul and I am identified by the given name.= =A0 Likewise, =93/.well-known/webfinger=94 is often referred to as the reso= urce.=A0 It=92s not the resource, but it=92s the name of the resource.

=A0<= /p>

In section 4.1 we (I t= hink you) introduced text to help clarify what we mean by a URI parameter. = =A0The intent was to not have to have so much verbosity every time we talk = about a URI parameter.

=A0<= /p>

What Peter suggested t= o me separately is that we put the name of the well-known location in quote= s.=A0 Thus, we have:

=A0<= /p>

=A0=A0=A0 A WebFinger = client issues a query to the well-known [3] resource =93/.well-known/webfin= ger=94

=A0<= /p>

I agree we need to be = precise, but it makes the text more difficult to read.=A0 What=92s a reason= able compromise?

=A0<= /p>

The Co-Author Identifi= ed by the Given Name Paul ;-)

=A0<= /p>

From: webfinger-bounces@ietf.o= rg [mailto:webfinger-bounces@ietf.org] On Behalf Of Tim Bray
Sent: Monday, February 04, 2013 11:49 PM
To: Gonzalo Salgu= eiro
Cc: Salvatore Loreto; Brad Fitzpatrick; Murray Kucherawy; Pe= ter Saint-Andre; we= bfinger@ietf.org
Subject: Re: [webfinger] Working Group Last Call for draft-ietf-apps= awg-webfinger-09

=A0

One editorial issue, which has no effect on the actual normative effect.=A0= 4.2 says =93A WebFinger client issues a query to the well-known [3] resour= ce
=A0=A0 /.well-known/webfinger.=94=A0

Um, not really; that isn= =92t a resource, that=92s part of a URI.=A0 Language should be along the li= nes of =93It issues a query to the resource identified by the URI whose pat= h component begins with =93/.well-known/webfinger?=94 and whose query compo= nent MUST include include the "resource" parameter exactly....=94= [proceed as before].

I=92d say I hate to be pedantic, but evidence = would be against me.=A0 In my defense, publications of the IETF should be c= areful of their nomenclature about important things like resources and URIs= .=A0 -T

=A0=

On Mon, Feb 4, 2013 at 8:08 PM, Gonz= alo Salgueiro <g= salguei@cisco.com> wrote:


On Feb 4, 20= 13, at 5:58 PM, Peter Saint-Andre <stpeter@stpeter.im> wrote:

> -----BEGIN= PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 2/1/13 10:12 AM, Brad Fitzpatrick wrote:=
>> +1
>>
>> Looks good to me.
>
> H= ere too. I sent a bunch of editorial feedback to the authors, but I
> see no substantive technical problems here. Kudos to the authors for> their work on the spec!

Thanks for the extremely detailed review. =A0Upon quick inspection the su= ggested edits seem perfectly reasonable. =A0The post WGLC version will incl= ude these.

Gonzalo


>
> Peter
>
> - --
>= Peter Saint-Andre
> https://stpeter.im/
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/M= acGPG2 v2.0.18 (Darwin)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net= /
>
> iEYEARECAAYFAlEQPTAACgkQNL8k5A2w/vwi/ACgnjcwR3jTFcbfGebjtiXduy= dT
> /gEAoK0SpA17y08zxtJB8vNidYqM9Kds
> =3DRV/l
> -----EN= D PGP SIGNATURE-----
> ______________________________________________= _
> webfinger mailing list
> webfinger@ietf.org
> https://www.ietf.org/mai= lman/listinfo/webfinger
>

_______________________________________________
webfinger ma= iling list
webfi= nger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger=

=A0

<= /div>

=A0

=A0

=

--e89a8ff242a101ad6f04d51c71b7-- From sm@resistor.net Wed Feb 6 00:23: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 1057121F8681 for ; Wed, 6 Feb 2013 00:23:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zuM3OB3JVvm for ; Wed, 6 Feb 2013 00:23:10 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1902E21F865B for ; Wed, 6 Feb 2013 00:23:09 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r168Mq9D027229; Wed, 6 Feb 2013 00:22:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1360138978; bh=0cR2oO5ImzRKcuxGBIljNf5lsGw0dsTlPFXXVytiWUQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=W1OpdOzQyXsEHZrADjUJiTRVoBWcn/cURA4H7FnnUaJfEmRpSQF4zWr874KjN45cs Nk1aHPjJPMA0a3vLQQIYyvNBv0r3FwLHKNnM4+z8uuuwXMNfWqYtip2i1y8Q/6n21c TY42FPuyfYviijiQhNN3bn0r1wS4PBBNwNC5VlrA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1360138978; i=@resistor.net; bh=0cR2oO5ImzRKcuxGBIljNf5lsGw0dsTlPFXXVytiWUQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=g420/zFGsvuN/60Z+AUAgmvpfo1BsfXS+OKXDXrWGEzrR3rlkGyZnau2Z6isQ3Dwj 2ZOgbRRGuGPLNz2tPZveGTN73p3xqoj8sTKf0O4j5s/Vlz9owd+mb5G8cpnHOp3uVr ACydWlJjUe5dHEfdWHp3iu684LayuVrz/Uy60HRg= Message-Id: <6.2.5.6.2.20130205235612.0940efe0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 06 Feb 2013 00:21:55 -0800 To: "Paul E. Jones" , Salvatore Loreto From: SM In-Reply-To: <044b01ce042e$965e1d00$c31a5700$@packetizer.com> References: <5106BFDC.2030706@ericsson.com> <5106C090.8080403@ericsson.com> <6.2.5.6.2.20130131151432.0aaf2b68@resistor.net> <044b01ce042e$965e1d00$c31a5700$@packetizer.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailman-Approved-At: Wed, 06 Feb 2013 23:40:21 -0800 Cc: webfinger@ietf.org, James M Snell Subject: Re: [webfinger] [apps-discuss] Working Group Last Call for draft-ietf-appsawg-webfinger-09 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, 06 Feb 2013 08:23:11 -0000 Hi Paul, At 21:55 05-02-2013, Paul E. Jones wrote: >You just want to replace all references to webfinger.net with something like >example.com or webfinger.example? I mentioned this as the IESG may raise it as an issue. I don't have any preference. >This is just an example. That said, I'd personally prefer to use WF to >solve this kind of problem than SRV records. The SRV approach presents >certain administrative challenges and it's not tailored for a specific user. >Rather, it applies to the whole domain. So, if you and I have accounts on >packetizer.com, for example, there is no means of telling our respective >mail clients which server to use if our mailbox accounts are provisioned on >different servers. > >I believe Cyrus is still working to come up with the best solution to this >provisioning issue. Thanks for explaining this. I read "Proposed Standard" as the standardized way to solve problem X. I'll leave it to the working group to see what it wants to do about the point I mentioned previously. >"Servers SHOULD support for the "rel" parameter" Ok. >Now reads: > > 'The value of the "rel" member MUST contain exactly one URI > or registered relation type.' That sounds better. >I do not think we should replace this simple explanation with a reference to >a 95-page document. Nobody needs to be a mail server expert to read what is >written there now. One only needs to understand the high-level idea. I'm >not opposed to adding an informative reference, if you think that helps. I >just don't think it does. I am not arguing for an informative reference as I am not the author of that RFC. :-) My point is that a draft gets a lot of additional text if I explain what is already explained in another specification. It can cause divergence if there are different interpretations of what the text means in that other specification means. >Separately, Peter suggested a reference to RFC 2818, so I inserted that. >Should it be 6125? I'll leave it to Peter to argue this one as he knows RFC 6125 better. >"... implicitly consented by..."? > >Or, >"... implicitly approved by ..."? >"... implicitly agreed by ..."? >"... implicitly allowed by ..."? > >Personally, I like "authorized", but I'll take suggestions. If we want >"consent", I would suggest re-wording as: > >"unless consent is obtained explicitly or implicitly from the person whose >information is being shared" [snip] >James wanted that. > >James, can we strike that sentence? See my comment to James. Regards, -sm From mnot@mnot.net Wed Feb 6 21:44: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 8CB9621E8040 for ; Wed, 6 Feb 2013 21:44:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.479 X-Spam-Level: X-Spam-Status: No, score=-105.479 tagged_above=-999 required=5 tests=[AWL=-2.880, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FpoOwKjz4iww for ; Wed, 6 Feb 2013 21:44:43 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 7E1FB21F850E for ; Wed, 6 Feb 2013 21:44:43 -0800 (PST) Received: from [192.168.1.80] (unknown [118.209.138.158]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id AF97B22E1F3; Thu, 7 Feb 2013 00:44:36 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Mark Nottingham In-Reply-To: <046e01ce0437$43df8ec0$cb9eac40$@packetizer.com> Date: Thu, 7 Feb 2013 16:44:32 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <046e01ce0437$43df8ec0$cb9eac40$@packetizer.com> To: Paul E. Jones X-Mailer: Apple Mail (2.1499) X-Mailman-Approved-At: Wed, 06 Feb 2013 23:40:21 -0800 Cc: webfinger@ietf.org Subject: Re: [webfinger] [apps-discuss] WGLC feedback on webfinger-09 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, 07 Feb 2013 05:44:45 -0000 On 06/02/2013, at 5:57 PM, Paul E. Jones wrote: > Mark, >=20 >> 1) The introduction seems to be missing a vital bit of information: = that >> the Whole Point -- the Big Trick -- that WebFinger performs is (AIUI) >> that you can use an identifier that might not be usable as a locator >> (e.g., a mailto: uri, an acct: uri) as a locator. In that sense, it's >> really just a more real-world-usable URN lookup facility*. >>=20 >> This is really important to include in the abstract as well as the >> introduction, because without it, WF just seems like a silly = indirection >> mechanism on top of HTTP. >=20 > Do you have suggested wording? As I pondered on the abstract, I only = made > it more complex. """ WebFinger is a protocol for locating information about various types of = URIs that might not be usable as a locator otherwise. For example, = mailto: and acct: URIs can be used to identify e-mail and localised = accounts, but they do not provide an in-built way to discover and convey = additional information about the identifier. WebFinger builds on top of HTTP [ref], TLS [ref], JSON [ref] and Web = Linking [ref] to provide this service, through a well-known [ref] HTTPS = URI on the same host as the URI's authority. Note that WebFinger cannot = be used to find information about URIs that do not have an authority = (e.g., URNs). """ That could replace the abstract and the first paragraph of the intro. >> 2) The examples use unregistered link relations types >> ; >> specifically, "blog" and "vcard". Naughty. >=20 > Yeah, but there is an intent to register both of those. You're the = expert > here: any reason these could not be registered for their intended = purposes? > (We can use URIs here, but the group preferred to use these type = names.) Putting unregistered ANYTHING in an RFC is bad -- especially if it looks = vaguely useful. Register them or change them, before publishing. Since "text/vcard" is = already a media type, you might want to re-think that one before doing = so; it's likely to have problems as-is. >> 3) The text in section 4.1 isn't precise enough; consider the "=3D" = and >> "&" characters, which are NOT required to be percent-encoded by = RFC3986 >> section 2.1. Also, the things that section is defining are not "URI >> parameters" (which is things after a semicolon in a path segment); = it's >> a query string format. Really, what you want to do is either: a) >> reference or re-define >> = > www-form-urlencoded-encoding-algorithm>, or b) define a subset of it >> that's simple yet precise. >=20 > I forgot who offered this text. It might have been either Tim or = Dick. >=20 > I received other suggested wording. I currently have this: >=20 > "This specification defines URI parameters that are passed from the = client > to the server when issuing a request. These parameters, "resource" = and > "rel", and the parameter values are included in the "query" component = of the > URI (see Section 3.4 of RFC 3986). To construct the "query" = component, the > client performs the following steps. First, each parameter value is > percent-encoded as per Section 2.1 of RFC 3986. Next, the client = constructs > a string to be placed in the query component by concatenating the name = of > the first parameter together with an equal sign ("=3D") and the > percent-encoded parameter value. For any subsequent parameters, the = client > appends an ampersand ("&") to the string, the name of the next = parameter, an > equal sign, and the parameter value (percent-encoded as needed). The = client > MUST NOT insert any spaces while constructing the string. The order = in > which the client places each attribute-and-value pair within the query > component is unspecified." >=20 > Exactly what should we change? ?? I reported an obvious bug and suggested three different ways to fix = it. What more do you want? >> 4) Section 4.2 would be a lot clearer if you just said that the well- >> known location is ONLY defined for the HTTPS URI scheme. >=20 > There are several things said in that section that are not related to = HTTPS. > Exactly what are you suggesting we change? I think I'd change the top of Section 4 to be: """ A Webfinger Resource is a well-known URI [ref] using the HTTPS scheme. = Webfinger resources MUST NOT be served with any other URI scheme (such = as HTTP). GET requests to a WebFinger resource convey the URI to perform the query = upon in the URI's query string; see [ref to 4.1] for details.=20 """ Then, edit the rest of 4.x to fit with that.=20 BTW, what's the difference between 4.1 "Constructing a WebFinger Query" = and 4.2 "Performing a WebFinger Query"? Are these really two separate = steps that justify their own subsections? Also, consider replacing "WebFinger server" with "WebFinger Resource". >> 5) Why not define a media type for JRD? You can instruct clients to = also >> accept application/json if you're worried about bad server >> configurations. >=20 > This was discussed separately. What's the point of an application = type for > a JSON object that exists only in this context? There do not seem to = be > many people defining JSON-specific sub-types, either. There are a = gazillion > +xml registrations and it's a bit of a mess, IMO. This is the Web; we identify formats with media types. How do you know = it's only ever going to "exist only in this context"? >> 6) What's the motivation for expires, given that HTTP caching >> information is already available? Have you considered the interaction >> between them? >=20 > Expires is defined in XRD and the already-defined JRD in RFC 6415. That's a really weak justification. This spec can choose to deprecate it = when used with WebFinger. What's it actually used for? Especially since = that, by definition, this protocol ONLY works over HTTP? > There is > no discussion on the interaction between the HTTP caching and the JRD > expires value. Really? What happens when the HTTP response has a large freshness = lifetime (either explicit or heuristic), but a smaller expires window?=20= > But, these are at two different layers in the stack. > Whatever generates a JRD may be a level removed from the HTTP server. > Likewise on the receiving end that processes a JRD. That's weak. You're happy to use the query string, so the server side = will have access to HTTP headers. Very, VERY few clients these days = don't have access to HTTP headers. >> 7) Section 4.4.5 "user's preferred link relation." --> "user's = preferred >> link relation type." (and likely elsewhere). >=20 > This is referring to multiple link relations of the same type. If = there are > multiple link relations of the same type, the first one is the user's > preferred link relation. >=20 > That is, if I insert three link relations of type "avatar" into a JRD, = the > first one if my preferred avatar. Hmm. In that case, it would just be "links" not "link relations". >> 8) RFC5988 defines the "target IRI" as what's at the end of the link; >> here, "linked resource" is used (e.g., 4.4.5.[2,3]). Suggest "target >> resource" as a way to tie them together conceptually. >=20 > Just replace "linked resource" with "target resource"? Yes. >> 9) Similarly, an important concept in 5988 is the "context" of the = link; >> suggest saying that the context of all of these links is the = subject(s). >=20 > Can you suggest words to add? At the top of 4.4.5: """ The "links" array has any number of member objects, each of which = represents a link [RFC5988]. Each of these link objects can have the = following members: * rel * type * href * titles * properties The "rel" and "href" members are strings representing the link's = relation type and the target IRI, respectively. The context of the link = is the subject [ref to subject]. The "type" member is a string indicating what the media type of the = result of dereferencing the link ought to be. """ BTW, 4.4.5 uses "elements" several times. JSON doesn't have elements; = the only containment relationships are object members and array members. >> 10) What if a target resource supports multiple media types for the = same >> relation? Suggest allowing multiple values in "type." >=20 > This would require a change in the syntax, which I'd rather not do at = this > point. However, this can be accomplished by defining two array = elements, > both having the same "rel" value, but having a different "type" value. I'd like to hear the WG response in addition to the editors' response. >> 11) 4.5 says "WebFinger requests can include a parameter = specifying..." >> What kind of parameter? Tie it back to what happens in 4.1. >=20 > This is just the "resource" parameter. Perhaps it's clearer if = written this > way: >=20 > 'WebFinger requests can include a "resource" parameter specifying...' The core problem is that "parameter" is not well-defined in this = specification. See earlier feedback. =20 >> 14) In section 7 (and likely elsewhere), you should use the full URL, >> not just the path /.well-known/webfinger, to make it clear that this = is >> just over HTTPS. >=20 > Are you referring to the examples? Yes. > That is what the protocol would look > like on the wire. If you're referring to the text like this: >=20 > 'When a query is issued to "/.well-known/webfinger", the web = server...' >=20 > The challenge there is that I need a hostname and I would not want to = put > "example.com" there. Perhaps it might be better to just say: >=20 > 'When a query is issued to the WebFinger resource, the web server...' >=20 > But, that would not help clarify the use of HTTPS. But, use of HTTPS = is > stated so many times in the doc, I don't think people will screw that = up. That could work. An alternative would be "When a query is issued to the "/.well-known/webfinger" resource on an = HTTPS Web server..."=20 However, I think I like your formulation better, provided that = "webfinger resource" is well-defined (see above). Cheers, -- Mark Nottingham http://www.mnot.net/ From paulej@packetizer.com Thu Feb 7 00:32:34 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 126A821F8554 for ; Thu, 7 Feb 2013 00:32:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BtgaYkW4E-v8 for ; Thu, 7 Feb 2013 00:32:31 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id AE14621F855A for ; Thu, 7 Feb 2013 00:32:31 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r178WUE8000481 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Feb 2013 03:32:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1360225951; bh=hsM0EKqxiU6OjJgAo8pfkptuISSs3oljVHuKFcAtm70=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Sbpks1bhN4OJc00yucK4fUJ3KEKzwbZldGXrv4s4kmlbrGAJmq4rB5A1hXycyF2tW 6NmaBf0slw96Is8+T4gAqhVJDHAfCXcoTx/shvrk882Y47OI6GQnmUHZZ4H1pBLMwt YhtCglsAyirGq9ZBcg/d5Lg+cRIG+muBVq1Kglso= From: "Paul E. Jones" To: "'Mark Nottingham'" References: <046e01ce0437$43df8ec0$cb9eac40$@packetizer.com> In-Reply-To: Date: Thu, 7 Feb 2013 03:32:39 -0500 Message-ID: <076a01ce050d$b0a8f6a0$11fae3e0$@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: AQK/nJvLr+z8azcZ5q9IuXWd/66KiwIIYIiqAvf8rVqWYrg0cA== Content-Language: en-us Cc: webfinger@ietf.org Subject: Re: [webfinger] [apps-discuss] WGLC feedback on webfinger-09 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, 07 Feb 2013 08:32:34 -0000 Mark, > > Do you have suggested wording? As I pondered on the abstract, I only > > made it more complex. > > """ > WebFinger is a protocol for locating information about various types of > URIs that might not be usable as a locator otherwise. For example, > mailto: and acct: URIs can be used to identify e-mail and localised > accounts, but they do not provide an in-built way to discover and convey > additional information about the identifier. > > WebFinger builds on top of HTTP [ref], TLS [ref], JSON [ref] and Web > Linking [ref] to provide this service, through a well-known [ref] HTTPS > URI on the same host as the URI's authority. Note that WebFinger cannot > be used to find information about URIs that do not have an authority > (e.g., URNs). > """ > > That could replace the abstract and the first paragraph of the intro. Concerns with this text: 1) It removes the words "discover information about people or other entities". While what you wrote is correct, if I were not familiar with WF, it would not immediately strike me as a protocol used for discovering information about people. I think that's needed. 2) I don't think we should have references in the abstract, but if we can leave them out (since they're referenced later), that's OK 3) Replacing the first paragraph in the intro with the above makes the second sentence seem entirely out of place. It does not flow smoothly. 4) WebFinger can be used with URNs, but we don't talk about it. For example, folks have expressed interest in using it for tel: URIs. That would work just fine, but one just has to have a client that knows what WF server to talk to. I don't think we should so radically change these two sections, but I am still open to introducing something here to make your point. > >> 2) The examples use unregistered link relations types > >> ; > >> specifically, "blog" and "vcard". Naughty. > > > > Yeah, but there is an intent to register both of those. You're the > > expert > > here: any reason these could not be registered for their intended > purposes? > > (We can use URIs here, but the group preferred to use these type > > names.) > > Putting unregistered ANYTHING in an RFC is bad -- especially if it looks > vaguely useful. OK, I can change them. I'm not sure what to change them to, though. I guess another URI. I'd like to have at least one example that is not a URI. Perhaps I should replace one of those with something already registered. I'll have to ponder this one. (Comments, anyone?) > Register them or change them, before publishing. Since "text/vcard" is > already a media type, you might want to re-think that one before doing > so; it's likely to have problems as-is. Why would that present an issue? That's a different registry. > >> 3) The text in section 4.1 isn't precise enough; consider the "=" and > >> "&" characters, which are NOT required to be percent-encoded by > >> RFC3986 section 2.1. Also, the things that section is defining are > >> not "URI parameters" (which is things after a semicolon in a path > >> segment); it's a query string format. Really, what you want to do is > >> either: a) reference or re-define > >> >> x- > >> www-form-urlencoded-encoding-algorithm>, or b) define a subset of it > >> that's simple yet precise. > > > > I forgot who offered this text. It might have been either Tim or Dick. > > > > I received other suggested wording. I currently have this: > > > > > > Exactly what should we change? > > ?? I reported an obvious bug and suggested three different ways to fix > it. What more do you want? The text that is there was offered by somebody in order to try to make it clear as to how to present these parameters. Section 2.1 does not say = or & are or are not to be encoded, but merely says that "octet's corresponding character is outside the allowed set or is being used as a delimiter of, or within, the component" are encoded as explained in that section. When the text was proposed, I had no challenge understanding exactly what to do. So, this is why I'm having trouble understanding what to change. You call it an obvious bug, but it's not so obvious there is a bug to me. I would prefer to not refer to the HTTP spec, as I think that is more challenging to read than either the other RFC or the text currently in the WF spec. Not sure how to address your concern. Here's the current text: ` This specification defines parameters that are passed from the client to the server when issuing a request. These parameters, "resource" and "rel", and the parameter values are included in the "query" component of the URI (see Section 3.4 of RFC 3986). To construct the "query" component, the client performs the following steps. First, each parameter value is percent-encoded as per Section 2.1 of RFC 3986. Next, the client constructs a string to be placed in the query component by concatenating the name of the first parameter together with an equal sign ("=") and the percent-encoded parameter value. For any subsequent parameters, the client appends an ampersand ("&") to the string, the name of the next parameter, an equal sign, and the parameter value (percent-encoded as needed). The client MUST NOT insert any spaces while constructing the string. The order in which the client places each attribute-and-value pair within the query component is unspecified.' > >> 4) Section 4.2 would be a lot clearer if you just said that the well- > >> known location is ONLY defined for the HTTPS URI scheme. > > > > There are several things said in that section that are not related to > HTTPS. > > Exactly what are you suggesting we change? > > I think I'd change the top of Section 4 to be: > > """ > A Webfinger Resource is a well-known URI [ref] using the HTTPS scheme. > Webfinger resources MUST NOT be served with any other URI scheme (such > as HTTP). > > GET requests to a WebFinger resource convey the URI to perform the query > upon in the URI's query string; see [ref to 4.1] for details. > """ > > Then, edit the rest of 4.x to fit with that. That sounds good. How is this: `A Webfinger resource is a well-known URI [3] using the HTTPS scheme. Webfinger resources MUST NOT be served with any other URI scheme (such as HTTP). GET requests to a WebFinger resource convey the URI to perform the query upon in the URI's query string; see Section 4.1 for details. WebFinger returns a JSON Resource Descriptor (JRD) to convey information about an entity on the Internet and utilizes the Cross-Origin Resource Sharing (CORS) [9] specification to facilitate queries made via a web browser.' The last paragraph switches from > BTW, what's the difference between 4.1 "Constructing a WebFinger Query" > and 4.2 "Performing a WebFinger Query"? Are these really two separate > steps that justify their own subsections? Section 4.1 is really about constructing the Request URI. Perhaps the title should be: "Constructing a WebFinger Request URI" Would that be better? > Also, consider replacing "WebFinger server" with "WebFinger Resource". That might be doable, but I need to look through the whole document. We use "server" in a lot of places. We also use the word client a lot, as the terminology used has been client/server centric. So, I need to ensure the wording sounds right. I'm sure I'll mess that up ;-) How do others feel about this one? > >> 5) Why not define a media type for JRD? You can instruct clients to > >> also accept application/json if you're worried about bad server > >> configurations. > > > > This was discussed separately. What's the point of an application > > type for a JSON object that exists only in this context? There do not > > seem to be many people defining JSON-specific sub-types, either. > > There are a gazillion > > +xml registrations and it's a bit of a mess, IMO. > > This is the Web; we identify formats with media types. How do you know > it's only ever going to "exist only in this context"? A WF resource is an HTTP resource with a specific means defined of accessing the resource. If there ever was some other context, then it's not WF. There are tons of web services out there using JSON today and they don't all have their own media types. IANA would be employed all day on that problem if folks did register every separate use of JSON. > >> 6) What's the motivation for expires, given that HTTP caching > >> information is already available? Have you considered the interaction > >> between them? > > > > Expires is defined in XRD and the already-defined JRD in RFC 6415. > > That's a really weak justification. This spec can choose to deprecate it > when used with WebFinger. What's it actually used for? Especially since > that, by definition, this protocol ONLY works over HTTP? I have no use for it, but wanted to maintain compatibility with RFC 6415 since there are some folks who are using RFC 6415 and would appreciate not breaking the existing defined format. However, I don't know what folks are doing with it now. I don't send it from my own server. > > There is > > no discussion on the interaction between the HTTP caching and the JRD > > expires value. > > Really? What happens when the HTTP response has a large freshness > lifetime (either explicit or heuristic), but a smaller expires window? Then somebody has a bad implementation and a recipient is going to get stale data. > > But, these are at two different layers in the stack. > > Whatever generates a JRD may be a level removed from the HTTP server. > > Likewise on the receiving end that processes a JRD. > > That's weak. You're happy to use the query string, so the server side > will have access to HTTP headers. Very, VERY few clients these days > don't have access to HTTP headers. Well, it is. Consider the example where an email client performs a WF query. It's not a web browser, but an email client. Perhaps this email client is configured to automatically query the WF server for a sender as soon as the message is opened. It might maintain JRDs for a while, though, since they're convenient data structures. There might be a hash map on the email address to JRD structures in memory. The email application might ignore the HTTP headers entirely and the "client" in this case is some other part of the client that displays pictures or other information it can discover about a contact. The email client certainly could have access to the HTTP headers, but that might be a thread or two removed from the other code that is using the received JRD. The same might be said on the server side. In fact, it's quite likely even more true. JRDs might be created or stored on some sixth server down the line somewhere far removed from the HTTP server responding to the client request. There is even a more basic issue: what if the client and server clocks are different? Clients have to use some common sense. Let HTTP cache in whatever way it does. If a JRD is expired, use it, but discard it. It might be expired due to caching or just because the client and server clocks are not aligned. > >> 7) Section 4.4.5 "user's preferred link relation." --> "user's > >> preferred link relation type." (and likely elsewhere). > > > > This is referring to multiple link relations of the same type. If > > there are multiple link relations of the same type, the first one is > > the user's preferred link relation. > > > > That is, if I insert three link relations of type "avatar" into a JRD, > > the first one if my preferred avatar. > > Hmm. In that case, it would just be "links" not "link relations". OK > >> 8) RFC5988 defines the "target IRI" as what's at the end of the link; > >> here, "linked resource" is used (e.g., 4.4.5.[2,3]). Suggest "target > >> resource" as a way to tie them together conceptually. > > > > Just replace "linked resource" with "target resource"? > > Yes. Done. > >> 9) Similarly, an important concept in 5988 is the "context" of the > >> link; suggest saying that the context of all of these links is the > subject(s). > > > > Can you suggest words to add? > > At the top of 4.4.5: > > """ > The "links" array has any number of member objects, each of which > represents a link [RFC5988]. Each of these link objects can have the > following members: > > * rel > * type > * href > * titles > * properties > > The "rel" and "href" members are strings representing the link's > relation type and the target IRI, respectively. The context of the link > is the subject [ref to subject]. > > The "type" member is a string indicating what the media type of the > result of dereferencing the link ought to be. > """ OK.. I added that text. > BTW, 4.4.5 uses "elements" several times. JSON doesn't have elements; > the only containment relationships are object members and array members. Arrays have "elements". Presently, there is only one use of the word "elements" in 4.4.5 now and it is in reference to the things in the links array. So, I think it's OK. > >> 10) What if a target resource supports multiple media types for the > >> same relation? Suggest allowing multiple values in "type." > > > > This would require a change in the syntax, which I'd rather not do at > > this point. However, this can be accomplished by defining two array > > elements, both having the same "rel" value, but having a different > "type" value. > > I'd like to hear the WG response in addition to the editors' response. Buried in here? :) I might be the only one reading this deep. Do feel free to raise it up if you want, but we did go down the path of changing the syntax and such. I don't think this particular issue was raised before, though. Is this legal in the Web Linking spec? It appears the ABNF would allow for multiple "type" parameters, but I've never seen that. The contents of a type parameter, though, appears to be a single type. Perhaps I'm misreading that at this late hour. > >> 11) 4.5 says "WebFinger requests can include a parameter > specifying..." > >> What kind of parameter? Tie it back to what happens in 4.1. > > > > This is just the "resource" parameter. Perhaps it's clearer if > > written this > > way: > > > > 'WebFinger requests can include a "resource" parameter specifying...' > > The core problem is that "parameter" is not well-defined in this > specification. See earlier feedback. OK. I think the recent changes made to 4.1 will make that clearer. Obviously, it's hard for me to see that what I wrote is not clear in someone else's mind. ;-) > >> 14) In section 7 (and likely elsewhere), you should use the full URL, > >> not just the path /.well-known/webfinger, to make it clear that this > >> is just over HTTPS. > > > > Are you referring to the examples? > > Yes. I got rid of those entirely yesterday, so they ought not be an issue. > > That is what the protocol would look > > like on the wire. If you're referring to the text like this: > > > > 'When a query is issued to "/.well-known/webfinger", the web > server...' > > > > The challenge there is that I need a hostname and I would not want to > > put "example.com" there. Perhaps it might be better to just say: > > > > 'When a query is issued to the WebFinger resource, the web server...' > > > > But, that would not help clarify the use of HTTPS. But, use of HTTPS > > is stated so many times in the doc, I don't think people will screw > that up. > > That could work. An alternative would be > > "When a query is issued to the "/.well-known/webfinger" resource on an > HTTPS Web server..." > > However, I think I like your formulation better, provided that > "webfinger resource" is well-defined (see above). "resource" is OK, but we also have "WebFinger location" and "server" in different places. I like consistent terminology, but this is a "well-known location" that happens to be a REST "resource" that works like a client/server protocol. Makes my head hurt. Paul From paulej@packetizer.com Thu Feb 7 00:33:48 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 CF37721F8576 for ; Thu, 7 Feb 2013 00:33:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ooB0lwbzd0fc for ; Thu, 7 Feb 2013 00:33:43 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 68A7621F8551 for ; Thu, 7 Feb 2013 00:33:43 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r178XbP9000557 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Feb 2013 03:33:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1360226018; bh=td9Bcfwt/lg2+YVyMktF5uNmoDB6oR14JD+DAGhrYeA=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=EYY8DNvsStpzy2cnRmw1uEo3e1wRocBlBqoGpDLWPdmbVP+Lm/qjFRpQ02tEowo9U Zg5S+GXryb11lDOxRlivfi9UhSxL4gt9nLGyqR+Cj4tVy7ZFGupDtYyMjSj/96euqY D6s1ydSSairoagplzx9Rnxo4/YNFtEZdes8lhlh8= From: "Paul E. Jones" To: "'Tim Bray'" References: <5106BFDC.2030706@ericsson.com> <51103D30.2010701@stpeter.im> <548BEEAE-E92F-461F-B06F-ABB40EB9F22C@cisco.com> <041d01ce0427$95b16670$c1143350$@packetizer.com> <047001ce043a$2eee0c50$8cca24f0$@packetizer.com> <071201ce04f5$2c038590$840a90b0$@packetizer.com> <072a01ce04f9$d5e7d030$81b77090$@packetizer.com> In-Reply-To: Date: Thu, 7 Feb 2013 03:33:45 -0500 Message-ID: <076c01ce050d$d8a94a10$89fbde30$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_076D_01CE04E3.EFD5DA20" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE1BCY4ftSPh+1CSwbfjBRSkBwUGQKEsM7KArFjXBkCX9tzEAF0ZkifAfmawQgA8QJQmwKpRsb2AfpQevICnlahwgJP0EueAoxeIR8B5CP/npjQWZ4w Content-Language: en-us Cc: 'Gonzalo Salgueiro' , 'Murray Kucherawy' , 'Peter Saint-Andre' , 'Brad Fitzpatrick' , 'Salvatore Loreto' , webfinger@ietf.org Subject: Re: [webfinger] Working Group Last Call for draft-ietf-appsawg-webfinger-09 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, 07 Feb 2013 08:33:48 -0000 This is a multipart message in MIME format. ------=_NextPart_000_076D_01CE04E3.EFD5DA20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Ok, ok. I changed it. For the record, though, I drive a truck. ;-) Paul From: Tim Bray [mailto:tbray@textuality.com] Sent: Thursday, February 07, 2013 1:21 AM To: Paul E. Jones Cc: Salvatore Loreto; Peter Saint-Andre; Murray Kucherawy; webfinger@ietf.org; Brad Fitzpatrick; Gonzalo Salgueiro Subject: Re: [webfinger] Working Group Last Call for draft-ietf-appsawg-webfinger-09 If the WG is OK with ignoring the perfectly-clear terminology guidance from RFC3986, I'm certainly not going to lie down in the road over it. -T On Wed, Feb 6, 2013 at 10:10 PM, Paul E. Jones wrote: I'll note that says "should" and not even normatively. In every instance where we use URL, it is a locator. Unless we're striking the term URL entirely from the IETF vocabulary, I think it's more appropriate to use URL where we do. I'm perplexed by this sentence, actually. It reads like "we've invented cars and trucks, both of which are called automobiles. However, you should never refer to cars as cars or trucks as trucks. Rather, you should only speak of automobiles, even if you're referring only to a truck." Why? I must be missing something. Your favorite co-author identified by a name whose given component is Paul From: Tim Bray [mailto:tbray@textuality.com] Sent: Thursday, February 07, 2013 12:43 AM To: Paul E. Jones Cc: Salvatore Loreto; Peter Saint-Andre; Murray Kucherawy; webfinger@ietf.org; Brad Fitzpatrick; Gonzalo Salgueiro Subject: Re: [webfinger] Working Group Last Call for draft-ietf-appsawg-webfinger-09 Quoting from http://tools.ietf.org/html/rfc3986#section-1.1.3: "Future specifications and related documentation should use the general term "URI" rather than the more restrictive terms "URL" and "URN"" - your favorite Web-architecture pedant, T On Wed, Feb 6, 2013 at 9:37 PM, Paul E. Jones wrote: Actually, the revised text was using URI, but I should have used URL to be consistent with other parts of the document. Every place where we refer to the WebFinger resource, we say "URL". The acronym "URL" appears 5 times in the document. Most other places we use the term "URI" since the "href" can be any URI, the resource parameter is a URI, etc. Paul From: Tim Bray [mailto:tbray@textuality.com] Sent: Wednesday, February 06, 2013 11:07 AM To: Paul E. Jones Cc: Salvatore Loreto; Peter Saint-Andre; Murray Kucherawy; webfinger@ietf.org; Brad Fitzpatrick; Gonzalo Salgueiro Subject: RE: [webfinger] Working Group Last Call for draft-ietf-appsawg-webfinger-09 Thanks, looks good. I see you used the string "URL"; intentional, or did you mean URI? On Feb 5, 2013 11:18 PM, "Paul E. Jones" wrote: Ok, too tired to argue ;-) You're right, but. darn, that's verbose. It now reads: 'A WebFinger client issues a query to the well-known [3] resource identified by the URI whose path component begins with "/.well-known/webfinger" and whose query component MUST include the "resource" parameter exactly once and set to the value of the URI for which information is being sought.' To avoid further verbosity, I tried to sidestep the issue by replacing "/.well-known/webfinger" in the document (not the examples, but just the prose). Those changes are: Section 6: "As with all web resources, access to the WebFinger resource ..." Section 7: "When a query is issued to the WebFinger resource, ..." "This WebFinger service URL does not need to point to the well-known WebFinger location on the hosting service provider server." Are those other changes OK? Paul From: Tim Bray [mailto:tbray@textuality.com] Sent: Wednesday, February 06, 2013 12:17 AM To: Paul E. Jones Cc: Gonzalo Salgueiro; Salvatore Loreto; Brad Fitzpatrick; Murray Kucherawy; Peter Saint-Andre; webfinger@ietf.org Subject: Re: [webfinger] Working Group Last Call for draft-ietf-appsawg-webfinger-09 These things all live in the context of the WWW, and I think the nomenclature in http://www.w3.org/TR/webarch/ applies. The Web consists of Resources, which are identified by URIs, that's all there is to it. Per webfinger, there should be a resource identified by the URI "https://www.textuality.com/.well-known/webfinger?resource=acct:tbray@textua lity.com" On the other hand, "./well-known/webfinger" is not in any sane sense of the word a "resource", it's a string fragment you're using to assemble a URI to identify a particular webfinger resource. The webfinger spec describes how to construct the URI to identify the resource by specifying the construction of the path and query components of the URI. These are totally conventional web operations and should be referred to by conventional web terminology. -T On Tue, Feb 5, 2013 at 9:05 PM, Paul E. Jones wrote: Tim, I agree that this is the URI that identifies the resource. Even so, it is the resource. Consider, "Tim submitted a suggestion to the co-author Paul" vs. "Time submitted a suggestion to the co-author identified by the given name Paul" The second form and the first are the same. I am Paul and I am identified by the given name. Likewise, "/.well-known/webfinger" is often referred to as the resource. It's not the resource, but it's the name of the resource. In section 4.1 we (I think you) introduced text to help clarify what we mean by a URI parameter. The intent was to not have to have so much verbosity every time we talk about a URI parameter. What Peter suggested to me separately is that we put the name of the well-known location in quotes. Thus, we have: A WebFinger client issues a query to the well-known [3] resource "/.well-known/webfinger" I agree we need to be precise, but it makes the text more difficult to read. What's a reasonable compromise? The Co-Author Identified by the Given Name Paul ;-) From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of Tim Bray Sent: Monday, February 04, 2013 11:49 PM To: Gonzalo Salgueiro Cc: Salvatore Loreto; Brad Fitzpatrick; Murray Kucherawy; Peter Saint-Andre; webfinger@ietf.org Subject: Re: [webfinger] Working Group Last Call for draft-ietf-appsawg-webfinger-09 One editorial issue, which has no effect on the actual normative effect. 4.2 says "A WebFinger client issues a query to the well-known [3] resource /.well-known/webfinger." Um, not really; that isn't a resource, that's part of a URI. Language should be along the lines of "It issues a query to the resource identified by the URI whose path component begins with "/.well-known/webfinger?" and whose query component MUST include include the "resource" parameter exactly...." [proceed as before]. I'd say I hate to be pedantic, but evidence would be against me. In my defense, publications of the IETF should be careful of their nomenclature about important things like resources and URIs. -T On Mon, Feb 4, 2013 at 8:08 PM, Gonzalo Salgueiro wrote: On Feb 4, 2013, at 5:58 PM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 2/1/13 10:12 AM, Brad Fitzpatrick wrote: >> +1 >> >> Looks good to me. > > Here too. I sent a bunch of editorial feedback to the authors, but I > see no substantive technical problems here. Kudos to the authors for > their work on the spec! Thanks for the extremely detailed review. Upon quick inspection the suggested edits seem perfectly reasonable. The post WGLC version will include these. Gonzalo > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iEYEARECAAYFAlEQPTAACgkQNL8k5A2w/vwi/ACgnjcwR3jTFcbfGebjtiXduydT > /gEAoK0SpA17y08zxtJB8vNidYqM9Kds > =RV/l > -----END PGP SIGNATURE----- > _______________________________________________ > 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_076D_01CE04E3.EFD5DA20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ok, ok… I changed it.

 

For the record, though, I drive a truck. ;-)

 

Paul

 

From:= = Tim Bray [mailto:tbray@textuality.com]
Sent: Thursday, = February 07, 2013 1:21 AM
To: Paul E. Jones
Cc: = Salvatore Loreto; Peter Saint-Andre; Murray Kucherawy; = webfinger@ietf.org; Brad Fitzpatrick; Gonzalo = Salgueiro
Subject: Re: [webfinger] Working Group Last Call for = draft-ietf-appsawg-webfinger-09

 

If the WG is OK with ignoring the = perfectly-clear terminology guidance from RFC3986, I’m certainly = not going to lie down in the road over it.

-T

 

On Wed, Feb 6, 2013 at 10:10 PM, Paul E. Jones <paulej@packetizer.com> = wrote:

I’ll note that says “should” and not even = normatively.

 

In every instance where we use URL, it is a locator.  Unless = we’re striking the term URL entirely from the IETF vocabulary, I = think it’s more appropriate to use URL where we = do.

 

I’m perplexed by this sentence, actually.  It reads like = “we’ve invented cars and trucks, both of which are called = automobiles.  However, you should never refer to cars as cars or = trucks as trucks.  Rather, you should only speak of automobiles, = even if you’re referring only to a = truck.”

 

Why?  I must be missing something.

 

Your favorite co-author identified by a name whose given component is = Paul

 

From:= = Tim Bray [mailto:tbray@textuality.com]
Sent: Thursday, = February 07, 2013 12:43 AM


To: Paul E. Jones
Cc: Salvatore = Loreto; Peter Saint-Andre; Murray Kucherawy; webfinger@ietf.org; Brad Fitzpatrick; Gonzalo = Salgueiro

Subject: Re: [webfinger] Working Group Last = Call for = draft-ietf-appsawg-webfinger-09

 <= /o:p>

Quoting from http://tools.ietf.org/html/rfc3986#section-1.1.3: = “Future specifications and related documentation should use the = general term "URI" rather than the more  restrictive = terms "URL" and "URN"”

- your = favorite Web-architecture pedant, T

 <= /p>

On Wed, Feb = 6, 2013 at 9:37 PM, Paul E. Jones <paulej@packetizer.com> = wrote:

Actually, the revised text was using URI, but I should have used URL = to be consistent with other parts of the document.  Every place = where we refer to the WebFinger resource, we say = “URL”.

 

The acronym “URL” appears 5 times in the = document.

 

Most other places we use the term “URI” since the = “href” can be any URI, the resource parameter is a URI, = etc.

 

Paul

 

From:= = Tim Bray [mailto:tbray@textuality.com]
Sent: Wednesday, = February 06, 2013 11:07 AM
To: Paul E. Jones
Cc: = Salvatore Loreto; Peter Saint-Andre; Murray Kucherawy; webfinger@ietf.org; Brad Fitzpatrick; Gonzalo = Salgueiro
Subject: RE: [webfinger] Working Group Last Call for = draft-ietf-appsawg-webfinger-09

 <= /o:p>

Thanks, looks good. I see you used the string = "URL"; intentional, or did you mean URI?

On Feb 5, = 2013 11:18 PM, "Paul E. Jones" <paulej@packetizer.com> = wrote:

Ok, too tired to argue ;-)  You’re right, but… darn, = that’s verbose.

 

It now reads:

 

‘A WebFinger client issues a query to the well-known [3] = resource identified by the URI whose path component begins with = “/.well-known/webfinger” and whose query component MUST = include the “resource” parameter exactly once and set to the = value of the URI for which information is being = sought.’

 

To avoid further verbosity, I tried to sidestep the issue by = replacing “/.well-known/webfinger” in the document (not the = examples, but just the prose).  Those changes = are:

 

Section 6:

“As with all web resources, access to the WebFinger resource = ...”

 

Section 7:

“When a query is issued to the WebFinger resource, = ...”

“This WebFinger service URL does not need to point to the = well-known WebFinger location on the hosting service provider = server.”

 

Are those other changes OK?

 

Paul

 

From:= = Tim Bray [mailto:tbray@textuality.com]
Sent: Wednesday, = February 06, 2013 12:17 AM
To: Paul E. Jones
Cc: = Gonzalo Salgueiro; Salvatore Loreto; Brad Fitzpatrick; Murray Kucherawy; = Peter Saint-Andre; webfinger@ietf.org
Subject: Re: = [webfinger] Working Group Last Call for = draft-ietf-appsawg-webfinger-09

 <= /o:p>

These things all = live in the context of the WWW, and I think the nomenclature in http://www.w3.org/TR/webarch/ applies.  The = Web consists of Resources, which are identified by URIs, that’s = all there is to it.

Per webfinger, there should be a resource = identified by the URI “https://www.textuality.com/.well-known/webfinger?resour= ce=3Dacct:tbray@textuality.com” On the other hand, = “./well-known/webfinger” is not in any sane sense of the = word a “resource”, it’s a string fragment you’re = using to assemble a URI to identify a particular webfinger = resource.

The = webfinger spec describes how to construct the URI to identify the = resource by specifying the construction of the path and query components = of the URI. These are totally conventional web operations and should be = referred to by conventional web terminology.  = -T

 <= /p>

On Tue, Feb = 5, 2013 at 9:05 PM, Paul E. Jones <paulej@packetizer.com> = wrote:

Tim,

 

I agree that this is the URI that identifies the resource.  Even = so, it is the resource.

 

Consider,

 

  “Tim submitted a suggestion to the co-author = Paul”

 

vs.

 

“Time submitted a suggestion to the co-author identified by the = given name Paul”

 

The second form and the first are the same.  I am Paul and I am = identified by the given name.  Likewise, = “/.well-known/webfinger” is often referred to as the = resource.  It’s not the resource, but it’s the name of = the resource.

 

In section 4.1 we (I think you) introduced text to help clarify what = we mean by a URI parameter.  The intent was to not have to have so = much verbosity every time we talk about a URI = parameter.

 

What Peter suggested to me separately is that we put the name of the = well-known location in quotes.  Thus, we = have:

 

    A WebFinger client issues a query to the = well-known [3] resource = “/.well-known/webfinger”

 

I agree we need to be precise, but it makes the text more difficult = to read.  What’s a reasonable = compromise?

 

The Co-Author Identified by the Given Name Paul = ;-)

 

From:= = webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of = Tim Bray
Sent: Monday, February 04, 2013 11:49 = PM
To: Gonzalo Salgueiro
Cc: Salvatore Loreto; Brad = Fitzpatrick; Murray Kucherawy; Peter Saint-Andre; webfinger@ietf.org
Subject: Re: = [webfinger] Working Group Last Call for = draft-ietf-appsawg-webfinger-09

 <= /o:p>

One editorial = issue, which has no effect on the actual normative effect.  4.2 = says “A WebFinger client issues a query to the well-known [3] = resource
   /.well-known/webfinger.”  =

Um, not really; that isn’t a resource, that’s part = of a URI.  Language should be along the lines of “It issues a = query to the resource identified by the URI whose path component begins = with “/.well-known/webfinger?” and whose query component = MUST include include the "resource" parameter = exactly....” [proceed as before].

I’d = say I hate to be pedantic, but evidence would be against me.  In my = defense, publications of the IETF should be careful of their = nomenclature about important things like resources and URIs.  = -T

 <= /p>

On Mon, Feb = 4, 2013 at 8:08 PM, Gonzalo Salgueiro <gsalguei@cisco.com> = wrote:


On Feb 4, = 2013, at 5:58 PM, Peter Saint-Andre <stpeter@stpeter.im> wrote:

> = -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On = 2/1/13 10:12 AM, Brad Fitzpatrick wrote:
>> = +1
>>
>> Looks good to me.
>
> Here too. I = sent a bunch of editorial feedback to the authors, but I
> see no = substantive technical problems here. Kudos to the authors for
> = their work on the spec!

Thanks for = the extremely detailed review.  Upon quick inspection the suggested = edits seem perfectly reasonable.  The post WGLC version will = include these.

Gonzalo


>
= > Peter
>
> - --
> Peter Saint-Andre
> https://stpeter.im/
>
>
> = -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.18 = (Darwin)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> = iEYEARECAAYFAlEQPTAACgkQNL8k5A2w/vwi/ACgnjcwR3jTFcbfGebjtiXduydT
> = /gEAoK0SpA17y08zxtJB8vNidYqM9Kds
> =3DRV/l
> -----END PGP = SIGNATURE-----
> = _______________________________________________
> 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

 <= /o:p>

 <= /o:p>

 <= /o:p>

 

------=_NextPart_000_076D_01CE04E3.EFD5DA20-- From barryleiba.mailing.lists@gmail.com Thu Feb 7 08:28: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 87CE821F81FF for ; Thu, 7 Feb 2013 08:28:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.478 X-Spam-Level: X-Spam-Status: No, score=-102.478 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YKhRDKNzqXnk for ; Thu, 7 Feb 2013 08:28:48 -0800 (PST) Received: from mail-ve0-f181.google.com (mail-ve0-f181.google.com [209.85.128.181]) by ietfa.amsl.com (Postfix) with ESMTP id E1E2E21F8439 for ; Thu, 7 Feb 2013 08:28:47 -0800 (PST) Received: by mail-ve0-f181.google.com with SMTP id d10so2486195vea.12 for ; Thu, 07 Feb 2013 08:28:47 -0800 (PST) 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=oydE+04DqXxM61n/yY/ThatI6gyQ97xBsTw+WpilyJQ=; b=hiOLBHo6GX9IXhl6PVB4DGpvZZJyMklBxY2a6K6CtbGugOfULAbi2tR62wHh6yobIs 8FdHxwcEQjJZrRB8TyEcGztD3OoaUUf1NFtVIm4gOXxFyMRiO9OXxOxXfncHvwkp6CmS n/ORGte/SiTj423Ye8Uwlworu60m5rjkFZsIf/l71CFqfrr8M1Kz9/29z4dBGvHJ4CkE 4iIXX+1e23pkJKb5jDp4YqhFmcExAPakh9UligIrpZyzqujavwQCukDTgdwK8bPjbe+E qqxlZucnpRvSK9iedtFKzmCsqtdom0HqFhqkj0h4hzeiMc/K175YxGzjd7PHEpKN/BEC DVqQ== MIME-Version: 1.0 X-Received: by 10.58.48.231 with SMTP id p7mr2543864ven.11.1360254527004; Thu, 07 Feb 2013 08:28:47 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.59.3.41 with HTTP; Thu, 7 Feb 2013 08:28:46 -0800 (PST) In-Reply-To: <072501ce04f7$feee5af0$fccb10d0$@packetizer.com> References: <072501ce04f7$feee5af0$fccb10d0$@packetizer.com> Date: Thu, 7 Feb 2013 11:28:46 -0500 X-Google-Sender-Auth: ZFEEUVVyuHMaiae2FAx1XI92zLs Message-ID: From: Barry Leiba To: "Paul E. Jones" Content-Type: text/plain; charset=ISO-8859-1 Cc: "webfinger@ietf.org" Subject: Re: [webfinger] Media type for 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, 07 Feb 2013 16:28:49 -0000 As I said in the other thread: the purpose of a media type is to tag your payload for situations where you don't know <> what it is. No, it's not sufficient to say whether it's plain text, XML, or JSON (for that matter, XML and JSON are plain text, aren't they?). You have to know the context. It may be that in your use case, or even in all the current use cases, you do know the context. But you can't guarantee that will always be true, and defined media types let us plan ahea. I can also assure you that you'll get pushback from the IESG on this point (and not only from me). This isn't just empty process: there's value in having a specific media type to tag data that's used for a specific purpose. Now, it's not a difficult thing to define a media type, and it's especially easy if you're already writing an RFC anyway. And it's also easy to use the media type -- why's it harder to tag something as, say, application/webfinger+json than as application/json? So, to two of your points, specifically: > And is WF going to be the first of a bunch of spec > that create a bunch of JSON media types like there were for +xml? Probably yes. > I prefer application/json, unless there is a technical reason someone can > bring to my attention to show why this is a bad idea. No, the question goes the other way 'round. Creating appropriate media types is how we do this, so it needs to be done unless you (or someone else) have a technical reason that *it* is a bad idea. Really: if it's just that you don't like it or think it's unnecessary, I get that and I sympathise, but that's not a valid reason (others and I have already said why we do think it's necessary). If you *do* have a reason that it's actively bad, state it and people will listen. Barry, Applications AD On Thu, Feb 7, 2013 at 12:57 AM, Paul E. Jones wrote: > Folks, > > Most of the comments received have been editorial. I've tried to capture > all of them, though there is the possibility one slips through. None seem > like showstoppers. > > However, one comment that I've not taken action on is defining a media type > for WebFinger. There are split views on this. Some are arguing we need > something and others say we don't. Some say it might be helpful if present, > but not everyone agrees. > > Personally, I'm in the camp that we do not need anything more than > application/json. A query to a WebFinger resource means one would get a WF > response and the application type is really not so important. It is > important to know that it's application/json vs. XML or plain text or other, > but to introduce something like application/jrd+json or some such seems like > overkill to me. I've not seen this done for the gazillion other web > services that use JSON. > > So, is there truly a need to have an dedicated type? If so, what should be > the name of this type? And is WF going to be the first of a bunch of spec > that create a bunch of JSON media types like there were for +xml? > > I prefer application/json, unless there is a technical reason someone can > bring to my attention to show why this is a bad idea. > > Paul From jasnell@gmail.com Thu Feb 7 08:58: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 1647D21F8431 for ; Thu, 7 Feb 2013 08:58:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.433 X-Spam-Level: X-Spam-Status: No, score=-2.433 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iHpg4zYQ8jmo for ; Thu, 7 Feb 2013 08:58:10 -0800 (PST) Received: from mail-ie0-x232.google.com (ie-in-x0232.1e100.net [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 5027321F8782 for ; Thu, 7 Feb 2013 08:58:10 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id c13so3735886ieb.37 for ; Thu, 07 Feb 2013 08:58:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=uWaAWjUHByoCSAsyG6R/uYPycBTbF0Qjv2JblPPFvc0=; b=qSmxhtV6n7ZLPitOOBjem89O4nEtVyS6r+D2Dc/BSZsqLG75OtXDiE7Y9lnlLw/IR1 xjvD/Ej4nZ1BwN8RDf24WC2ex+8A2zrrdGnK51as9XFgNq4zDO6BeXChov6Ct+r8/Kry yRgnxUk5rXZXmpdbIveAoi4NRsB5qaRZYxCqvMjG7g91tBKqQ7EuXvXsehk9qI0iP/tM 6YtPaqZkMMEbAxoA7ulsulca34Tk8kTmwewOYh/6owICxS//3rM1Zt8kMCrAO74+j/rJ ObZTrgJkyj9y8MIVC6O8ySqk3LmCJ66YfFWHsIKsY2235Pvj1S3x93JHlR4Ve/HMisHf 8aBA== X-Received: by 10.50.13.175 with SMTP id i15mr4329128igc.75.1360256289803; Thu, 07 Feb 2013 08:58:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.53.237 with HTTP; Thu, 7 Feb 2013 08:57:49 -0800 (PST) In-Reply-To: References: <046e01ce0437$43df8ec0$cb9eac40$@packetizer.com> From: James M Snell Date: Thu, 7 Feb 2013 08:57:49 -0800 Message-ID: To: Mark Nottingham Content-Type: text/plain; charset=UTF-8 Cc: "Paul E. Jones" , "webfinger@ietf.org" Subject: Re: [webfinger] [apps-discuss] WGLC feedback on webfinger-09 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, 07 Feb 2013 16:58:11 -0000 On Wed, Feb 6, 2013 at 9:44 PM, Mark Nottingham wrote: > [snip] >>> 5) Why not define a media type for JRD? You can instruct clients to also >>> accept application/json if you're worried about bad server >>> configurations. >> >> This was discussed separately. What's the point of an application type for >> a JSON object that exists only in this context? There do not seem to be >> many people defining JSON-specific sub-types, either. There are a gazillion >> +xml registrations and it's a bit of a mess, IMO. > > This is the Web; we identify formats with media types. How do you know it's only ever going to "exist only in this context"? > > IMHO, adding a media type for JRD is largely a harmless exercise. I'm not convinced it would be used all that much but there's no harm in having it and, if JRD does happen to be used in other contexts then it'll make things easier down the road. >>> 6) What's the motivation for expires, given that HTTP caching >>> information is already available? Have you considered the interaction >>> between them? >> >> Expires is defined in XRD and the already-defined JRD in RFC 6415. > > That's a really weak justification. This spec can choose to deprecate it when used with WebFinger. What's it actually used for? Especially since that, by definition, this protocol ONLY works over HTTP? > Generally agree with Mark on this one. I do see how the expires attribute could be useful if you're locally storing copies of JRD documents independent of an http cache but that's not a very important use case for me. I'd prefer to just rely on http caching. It's not something that I would lie down in the road for tho, I'd just simply ignore the attribute. [snip] >>> 10) What if a target resource supports multiple media types for the same >>> relation? Suggest allowing multiple values in "type." >> >> This would require a change in the syntax, which I'd rather not do at this >> point. However, this can be accomplished by defining two array elements, >> both having the same "rel" value, but having a different "type" value. > > I'd like to hear the WG response in addition to the editors' response. > > I don't believe multiple values for type are going to be necessary... nor have I really seen that pattern used extensively elsewhere. If multiple types are support for given relation at a given target, just provide two separate link objects in the JRD. - James From dick.hardt@gmail.com Thu Feb 7 09:02: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 E9C0821F8473 for ; Thu, 7 Feb 2013 09:02:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZOu64jZfVTR for ; Thu, 7 Feb 2013 09:02:25 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2B68A21F845A for ; Thu, 7 Feb 2013 09:02:25 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id kp1so1546127pab.17 for ; Thu, 07 Feb 2013 09:02:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=8A96fWwwFeY8u2ug+5lAe0St3tZJE35d6D1I4X/2hxw=; b=iaJqDOA03DiHZVAuApv2jxA1KjqI3cU5R9pQj2A+r/kVgw6jRF1JBCesTLUgyczJ/v oYI0N4W7I/JwQ6FZ/yB5/42gFAP9R/S8ElbA/uLqZ+Zrb8NgK1Qyqo71FbEVnxp5mg2i MCgfEiAIjihE6MzoIvQ9s7rMX68BDHWpRTxx4k6k8bV1cgyaXUr4BXuAqAjD7fhYWsOH a4ykx3cn9YWh8L/N8hf+6As13cYmP3tYVGl2FWQ/HhqnnJzVPhEHRmzetGR7JIFiD6Cb pwnrvQKiuUhdCE2UPnXrXPJZszrnjrIBlguYZ4Y2ReFZ8fWkMj/0zLgCo9GEYFkB/cp8 9yAw== X-Received: by 10.66.85.161 with SMTP id i1mr7378564paz.67.1360256544748; Thu, 07 Feb 2013 09:02:24 -0800 (PST) Received: from [172.16.33.108] ([206.108.25.22]) by mx.google.com with ESMTPS id z6sm21324961pav.3.2013.02.07.09.02.18 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Feb 2013 09:02:23 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dick Hardt In-Reply-To: Date: Thu, 7 Feb 2013 09:02:16 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <632DD91F-6715-473D-81EE-8C58686B13BA@gmail.com> References: <072501ce04f7$feee5af0$fccb10d0$@packetizer.com> To: Barry Leiba X-Mailer: Apple Mail (2.1499) Cc: "Paul E. Jones" , "webfinger@ietf.org" Subject: Re: [webfinger] Media type for 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, 07 Feb 2013 17:02:26 -0000 Barry To help the less knowledgeable such as myself, would you be kind enough = to point out some examples of similar protocols that are widely deployed = that defined a new media type? Myself as a developer, I don't know why I would need anything more than = JSON. That tells me how to parse the media. If the payload has a more = specific media, I can't use my existing tool chain that automatically = detects a JSON payload and parses it for me and hands my application an = object. -- Dick On Feb 7, 2013, at 8:28 AM, Barry Leiba wrote: > As I said in the other thread: the purpose of a media type is to tag > your payload for situations where you don't know <> what it > is. No, it's not sufficient to say whether it's plain text, XML, or > JSON (for that matter, XML and JSON are plain text, aren't they?). > You have to know the context. It may be that in your use case, or > even in all the current use cases, you do know the context. But you > can't guarantee that will always be true, and defined media types let > us plan ahea. >=20 > I can also assure you that you'll get pushback from the IESG on this > point (and not only from me). This isn't just empty process: there's > value in having a specific media type to tag data that's used for a > specific purpose. >=20 > Now, it's not a difficult thing to define a media type, and it's > especially easy if you're already writing an RFC anyway. And it's > also easy to use the media type -- why's it harder to tag something > as, say, application/webfinger+json than as application/json? >=20 > So, to two of your points, specifically: >=20 >> And is WF going to be the first of a bunch of spec >> that create a bunch of JSON media types like there were for +xml? >=20 > Probably yes. >=20 >> I prefer application/json, unless there is a technical reason someone = can >> bring to my attention to show why this is a bad idea. >=20 > No, the question goes the other way 'round. Creating appropriate > media types is how we do this, so it needs to be done unless you (or > someone else) have a technical reason that *it* is a bad idea. > Really: if it's just that you don't like it or think it's unnecessary, > I get that and I sympathise, but that's not a valid reason (others and > I have already said why we do think it's necessary). If you *do* have > a reason that it's actively bad, state it and people will listen. >=20 > Barry, Applications AD >=20 > On Thu, Feb 7, 2013 at 12:57 AM, Paul E. Jones = wrote: >> Folks, >>=20 >> Most of the comments received have been editorial. I've tried to = capture >> all of them, though there is the possibility one slips through. None = seem >> like showstoppers. >>=20 >> However, one comment that I've not taken action on is defining a = media type >> for WebFinger. There are split views on this. Some are arguing we = need >> something and others say we don't. Some say it might be helpful if = present, >> but not everyone agrees. >>=20 >> Personally, I'm in the camp that we do not need anything more than >> application/json. A query to a WebFinger resource means one would = get a WF >> response and the application type is really not so important. It is >> important to know that it's application/json vs. XML or plain text or = other, >> but to introduce something like application/jrd+json or some such = seems like >> overkill to me. I've not seen this done for the gazillion other web >> services that use JSON. >>=20 >> So, is there truly a need to have an dedicated type? If so, what = should be >> the name of this type? And is WF going to be the first of a bunch of = spec >> that create a bunch of JSON media types like there were for +xml? >>=20 >> I prefer application/json, unless there is a technical reason someone = can >> bring to my attention to show why this is a bad idea. >>=20 >> Paul > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger From tbray@textuality.com Thu Feb 7 09:17: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 0F01821F8431 for ; Thu, 7 Feb 2013 09:17:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.343 X-Spam-Level: X-Spam-Status: No, score=-3.343 tagged_above=-999 required=5 tests=[AWL=-0.367, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8JiAVufBU6CS for ; Thu, 7 Feb 2013 09:17:52 -0800 (PST) Received: from mail-oa0-f49.google.com (mail-oa0-f49.google.com [209.85.219.49]) by ietfa.amsl.com (Postfix) with ESMTP id B050F21F88DD for ; Thu, 7 Feb 2013 09:17:51 -0800 (PST) Received: by mail-oa0-f49.google.com with SMTP id j6so3013664oag.8 for ; Thu, 07 Feb 2013 09:17:51 -0800 (PST) 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=H7+76OJPLmZsepADbo+Ll9/8gCAUwNQ/012qcOIGOCk=; b=Y5D8SZzb18npw2cLMWel5cYO3OztL4IUnnRoT79/1gnpw/tljHZIAjqOB3Q3urMyIf AtosLI7BebKy/WbQSLWEv/NSVs+tdKgkdpGojFsjkbfV2b2694aSPqo1WITreC30oCFQ k5Qslww4DLYRmOma36v6ZAzEkwToxHP4t1rsCtPDrHCSU9a5x5yycL6FoEThFKGaFCs6 qSh3TSSbUz5+5n9Cjo5jsHJljdH41v30ignyxztlLvIDieRgZU1ZuZFWopyokHzp9B+P LJmeOmjq2mM4t1n+0hetwvelHcqj5NawcHDhvv1o6Cd0yGvfw0FQn12TCFDEgTygtBY8 LEvw== MIME-Version: 1.0 X-Received: by 10.60.21.101 with SMTP id u5mr1764268oee.71.1360257471035; Thu, 07 Feb 2013 09:17:51 -0800 (PST) Received: by 10.76.173.38 with HTTP; Thu, 7 Feb 2013 09:17:50 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: <632DD91F-6715-473D-81EE-8C58686B13BA@gmail.com> References: <072501ce04f7$feee5af0$fccb10d0$@packetizer.com> <632DD91F-6715-473D-81EE-8C58686B13BA@gmail.com> Date: Thu, 7 Feb 2013 09:17:50 -0800 Message-ID: From: Tim Bray To: Dick Hardt Content-Type: multipart/alternative; boundary=e89a8ff1c7325d3a7a04d5259fc0 X-Gm-Message-State: ALoCoQniLMPbwSlpS4wTFScMWIZEZdM2pBVZudvPIARoFVD/243Z4lFCYJRhxDSANBiVRc8kSJVU Cc: "Paul E. Jones" , Barry Leiba , "webfinger@ietf.org" Subject: Re: [webfinger] Media type for 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, 07 Feb 2013 17:17:53 -0000 --e89a8ff1c7325d3a7a04d5259fc0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, Feb 7, 2013 at 9:02 AM, Dick Hardt wrote: > Barry > > To help the less knowledgeable such as myself, would you be kind enough t= o > point out some examples of similar protocols that are widely deployed tha= t > defined a new media type? > I=92ve got a better idea; why don=92t we just stop arguing over this stupid bikeshed issue and do what our AD just asked us to do. -Tim > > Myself as a developer, I don't know why I would need anything more than > JSON. That tells me how to parse the media. If the payload has a more > specific media, I can't use my existing tool chain that automatically > detects a JSON payload and parses it for me and hands my application an > object. > > -- Dick > > On Feb 7, 2013, at 8:28 AM, Barry Leiba wrote: > > > As I said in the other thread: the purpose of a media type is to tag > > your payload for situations where you don't know <> what it > > is. No, it's not sufficient to say whether it's plain text, XML, or > > JSON (for that matter, XML and JSON are plain text, aren't they?). > > You have to know the context. It may be that in your use case, or > > even in all the current use cases, you do know the context. But you > > can't guarantee that will always be true, and defined media types let > > us plan ahea. > > > > I can also assure you that you'll get pushback from the IESG on this > > point (and not only from me). This isn't just empty process: there's > > value in having a specific media type to tag data that's used for a > > specific purpose. > > > > Now, it's not a difficult thing to define a media type, and it's > > especially easy if you're already writing an RFC anyway. And it's > > also easy to use the media type -- why's it harder to tag something > > as, say, application/webfinger+json than as application/json? > > > > So, to two of your points, specifically: > > > >> And is WF going to be the first of a bunch of spec > >> that create a bunch of JSON media types like there were for +xml? > > > > Probably yes. > > > >> I prefer application/json, unless there is a technical reason someone > can > >> bring to my attention to show why this is a bad idea. > > > > No, the question goes the other way 'round. Creating appropriate > > media types is how we do this, so it needs to be done unless you (or > > someone else) have a technical reason that *it* is a bad idea. > > Really: if it's just that you don't like it or think it's unnecessary, > > I get that and I sympathise, but that's not a valid reason (others and > > I have already said why we do think it's necessary). If you *do* have > > a reason that it's actively bad, state it and people will listen. > > > > Barry, Applications AD > > > > On Thu, Feb 7, 2013 at 12:57 AM, Paul E. Jones > wrote: > >> Folks, > >> > >> Most of the comments received have been editorial. I've tried to > capture > >> all of them, though there is the possibility one slips through. None > seem > >> like showstoppers. > >> > >> However, one comment that I've not taken action on is defining a media > type > >> for WebFinger. There are split views on this. Some are arguing we ne= ed > >> something and others say we don't. Some say it might be helpful if > present, > >> but not everyone agrees. > >> > >> Personally, I'm in the camp that we do not need anything more than > >> application/json. A query to a WebFinger resource means one would get > a WF > >> response and the application type is really not so important. It is > >> important to know that it's application/json vs. XML or plain text or > other, > >> but to introduce something like application/jrd+json or some such seem= s > like > >> overkill to me. I've not seen this done for the gazillion other web > >> services that use JSON. > >> > >> So, is there truly a need to have an dedicated type? If so, what > should be > >> the name of this type? And is WF going to be the first of a bunch of > spec > >> that create a bunch of JSON media types like there were for +xml? > >> > >> I prefer application/json, unless there is a technical reason someone > can > >> bring to my attention to show why this is a bad idea. > >> > >> 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 > --e89a8ff1c7325d3a7a04d5259fc0 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Thu, Feb 7, 2013 at 9:02 AM, Dick Hardt <dick.hardt= @gmail.com> wrote:
Barry

To help the less knowledgeable such as myself, would you be kind enough to = point out some examples of similar protocols that are widely deployed that = defined a new media type?

I=92ve got a = better idea; why don=92t we just stop arguing over this stupid bikeshed iss= ue and do what our AD just asked us to do.

=A0-Tim

=A0

Myself as a developer, I don't know why I would need anything more than= JSON. That tells me how to parse the media. If the payload has a more spec= ific media, I can't use my existing tool chain that automatically detec= ts a JSON payload and parses it for me and hands my application an object.<= br>
-- Dick

On Feb 7, 2013, at 8:28 AM, Barry Leiba <barryleiba@computer.org> wrote:

> As I said in the other thread: the purpose of a media type is to tag > your payload for situations where you don't know <<a priori&= gt;> what it
> is. =A0No, it's not sufficient to say whether it's plain text,= XML, or
> JSON (for that matter, XML and JSON are plain text, aren't they?).=
> You have to know the context. =A0It may be that in your use case, or > even in all the current use cases, you do know the context. =A0But you=
> can't guarantee that will always be true, and defined media types = let
> us plan ahea.
>
> I can also assure you that you'll get pushback from the IESG on th= is
> point (and not only from me). =A0This isn't just empty process: th= ere's
> value in having a specific media type to tag data that's used for = a
> specific purpose.
>
> Now, it's not a difficult thing to define a media type, and it'= ;s
> especially easy if you're already writing an RFC anyway. =A0And it= 's
> also easy to use the media type -- why's it harder to tag somethin= g
> as, say, application/webfinger+json than as application/json?
>
> So, to two of your points, specifically:
>
>> And is WF going to be the first of a bunch of spec
>> that create a bunch of JSON media types like there were for +xml?<= br> >
> Probably yes.
>
>> I prefer application/json, unless there is a technical reason some= one can
>> bring to my attention to show why this is a bad idea.
>
> No, the question goes the other way 'round. =A0Creating appropriat= e
> media types is how we do this, so it needs to be done unless you (or > someone else) have a technical reason that *it* is a bad idea.
> Really: if it's just that you don't like it or think it's = unnecessary,
> I get that and I sympathise, but that's not a valid reason (others= and
> I have already said why we do think it's necessary). =A0If you *do= * have
> a reason that it's actively bad, state it and people will listen.<= br> >
> Barry, Applications AD
>
> On Thu, Feb 7, 2013 at 12:57 AM, Paul E. Jones <paulej@packetizer.com> wrote:
>> Folks,
>>
>> Most of the comments received have been editorial. =A0I've tri= ed to capture
>> all of them, though there is the possibility one slips through. = =A0None seem
>> like showstoppers.
>>
>> However, one comment that I've not taken action on is defining= a media type
>> for WebFinger. =A0There are split views on this. =A0Some are argui= ng we need
>> something and others say we don't. =A0Some say it might be hel= pful if present,
>> but not everyone agrees.
>>
>> Personally, I'm in the camp that we do not need anything more = than
>> application/json. =A0A query to a WebFinger resource means one wou= ld get a WF
>> response and the application type is really not so important. =A0I= t is
>> important to know that it's application/json vs. XML or plain = text or other,
>> but to introduce something like application/jrd+json or some such = seems like
>> overkill to me. =A0I've not seen this done for the gazillion o= ther web
>> services that use JSON.
>>
>> So, is there truly a need to have an dedicated type? =A0If so, wha= t should be
>> the name of this type? =A0And is WF going to be the first of a bun= ch of spec
>> that create a bunch of JSON media types like there were for +xml?<= br> >>
>> I prefer application/json, unless there is a technical reason some= one can
>> bring to my attention to show why this is a bad idea.
>>
>> 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

--e89a8ff1c7325d3a7a04d5259fc0-- From barryleiba@gmail.com Thu Feb 7 09:29:34 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 39E9121F88F7 for ; Thu, 7 Feb 2013 09:29:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.811 X-Spam-Level: X-Spam-Status: No, score=-102.811 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGQHn3yeAxgz for ; Thu, 7 Feb 2013 09:29:33 -0800 (PST) Received: from mail-qe0-f48.google.com (mail-qe0-f48.google.com [209.85.128.48]) by ietfa.amsl.com (Postfix) with ESMTP id 7B48921F8859 for ; Thu, 7 Feb 2013 09:29:30 -0800 (PST) Received: by mail-qe0-f48.google.com with SMTP id 3so1281877qea.21 for ; Thu, 07 Feb 2013 09:29:30 -0800 (PST) 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=XTUxHK1OWFqZdjPAd5Hh8I5lXUT4/SjMhVyZogBHV6Y=; b=0ibNfgZ+V8zfUFqs1fquoJiRC4pZliC9xHcMtorQ5w+Mbinp8kL3I3M2CVbpPd86XZ eHQQnDEPLcaHKdFP4PvwGy/9IizBdWrU+7mY8N6hKHNyjM97Fo2RrmwO9VB1czYPDE4T 1/FVEz0U77z4pbvLr9sqf6dNyW5Wu0DCcbwDyL8MYcPKpegtdCxFy0INdSoRFQVUZQ/o i7IzDQNmhEAoWbKLlelnKSoro3I92wDothXL4qT0fFEriLNkLBlHzb9pCsjSkNT8Vd6k EpzIAa4/Vc/YrBLRIGD8ExOPM7dGndbML8PVDdyZp3w46rEnzo5F4qMZWJLeS6jbHocy M+yg== MIME-Version: 1.0 X-Received: by 10.224.176.19 with SMTP id bc19mr1001820qab.46.1360258170578; Thu, 07 Feb 2013 09:29:30 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.49.48.11 with HTTP; Thu, 7 Feb 2013 09:29:30 -0800 (PST) In-Reply-To: <632DD91F-6715-473D-81EE-8C58686B13BA@gmail.com> References: <072501ce04f7$feee5af0$fccb10d0$@packetizer.com> <632DD91F-6715-473D-81EE-8C58686B13BA@gmail.com> Date: Thu, 7 Feb 2013 12:29:30 -0500 X-Google-Sender-Auth: 00GDU27YPrnVfHgaxDGC1I3Mn7g Message-ID: From: Barry Leiba To: Dick Hardt Content-Type: text/plain; charset=ISO-8859-1 Cc: "Paul E. Jones" , "webfinger@ietf.org" Subject: Re: [webfinger] Media type for 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, 07 Feb 2013 17:29:34 -0000 > To help the less knowledgeable such as myself, would you be kind enough to point > out some examples of similar protocols that are widely deployed that defined a new > media type? Setting this aside for the moment (I'm on the IESG telechat right now)... > Myself as a developer, I don't know why I would need anything more than JSON. That > tells me how to parse the media. It does, but, as I said before, it doesn't tell you what to do with it. You don't know whether to hand it to your webfinger handler, or to some other thing that uses JSON objects. > If the payload has a more specific media, I can't use my existing tool chain that > automatically detects a JSON payload and parses it for me and hands my application > an object. This was the point of making the suffixes. If your tools look for the "+json" media type suffix, you know how to parse it. And from the rest of the media type, you know what handler to use once it's parsed. Barry From mnot@mnot.net Thu Feb 7 03:18: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 EBE7421F841C for ; Thu, 7 Feb 2013 03:18:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.409 X-Spam-Level: X-Spam-Status: No, score=-105.409 tagged_above=-999 required=5 tests=[AWL=-2.809, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KspkXUq8I5cY for ; Thu, 7 Feb 2013 03:17:59 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id E0CF021F8602 for ; Thu, 7 Feb 2013 03:17:58 -0800 (PST) Received: from [192.168.1.80] (unknown [118.209.138.158]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 84D0E22E253; Thu, 7 Feb 2013 06:17:51 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Mark Nottingham In-Reply-To: <076a01ce050d$b0a8f6a0$11fae3e0$@packetizer.com> Date: Thu, 7 Feb 2013 22:17:48 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <18645BD5-3F95-4EAC-8693-219539257FA5@mnot.net> References: <046e01ce0437$43df8ec0$cb9eac40$@packetizer.com> <076a01ce050d$b0a8f6a0$11fae3e0$@packetizer.com> To: Paul E. Jones X-Mailer: Apple Mail (2.1499) X-Mailman-Approved-At: Thu, 07 Feb 2013 10:34:11 -0800 Cc: webfinger@ietf.org Subject: Re: [webfinger] [apps-discuss] WGLC feedback on webfinger-09 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, 07 Feb 2013 11:18:01 -0000 On 07/02/2013, at 7:32 PM, Paul E. Jones wrote: > Mark, >=20 >>> Do you have suggested wording? As I pondered on the abstract, I = only >>> made it more complex. >>=20 >> """ >> WebFinger is a protocol for locating information about various types = of >> URIs that might not be usable as a locator otherwise. For example, >> mailto: and acct: URIs can be used to identify e-mail and localised >> accounts, but they do not provide an in-built way to discover and = convey >> additional information about the identifier. >>=20 >> WebFinger builds on top of HTTP [ref], TLS [ref], JSON [ref] and Web >> Linking [ref] to provide this service, through a well-known [ref] = HTTPS >> URI on the same host as the URI's authority. Note that WebFinger = cannot >> be used to find information about URIs that do not have an authority >> (e.g., URNs). >> """ >>=20 >> That could replace the abstract and the first paragraph of the intro. >=20 > Concerns with this text: > 1) It removes the words "discover information about people or other > entities". While what you wrote is correct, if I were not familiar = with WF, > it would not immediately strike me as a protocol used for discovering > information about people. I think that's needed. Agreed. > 2) I don't think we should have references in the abstract, but if we = can > leave them out (since they're referenced later), that's OK Yep. > 3) Replacing the first paragraph in the intro with the above makes the > second sentence seem entirely out of place. It does not flow = smoothly. Perhaps. Your turn :) > 4) WebFinger can be used with URNs, but we don't talk about it. For > example, folks have expressed interest in using it for tel: URIs. = That > would work just fine, but one just has to have a client that knows = what WF > server to talk to. Ah, interesting. > I don't think we should so radically change these two sections, but I = am > still open to introducing something here to make your point. OK. >>>> 2) The examples use unregistered link relations types >>>> = ; >>>> specifically, "blog" and "vcard". Naughty. >>>=20 >>> Yeah, but there is an intent to register both of those. You're the >>> expert >>> here: any reason these could not be registered for their intended >> purposes? >>> (We can use URIs here, but the group preferred to use these type >>> names.) >>=20 >> Putting unregistered ANYTHING in an RFC is bad -- especially if it = looks >> vaguely useful. >=20 > OK, I can change them. I'm not sure what to change them to, though. = I > guess another URI. I'd like to have at least one example that is not = a URI. > Perhaps I should replace one of those with something already = registered. > I'll have to ponder this one. (Comments, anyone?) >=20 >> Register them or change them, before publishing. Since "text/vcard" = is >> already a media type, you might want to re-think that one before = doing >> so; it's likely to have problems as-is. >=20 > Why would that present an issue? That's a different registry. Right, but part of the guidance about what's appropriate as a link = relation is that it's *not* format-specific. >>>> 3) The text in section 4.1 isn't precise enough; consider the "=3D" = and >>>> "&" characters, which are NOT required to be percent-encoded by >>>> RFC3986 section 2.1. Also, the things that section is defining are >>>> not "URI parameters" (which is things after a semicolon in a path >>>> segment); it's a query string format. Really, what you want to do = is >>>> either: a) reference or re-define >>>> = >>> x- >>>> www-form-urlencoded-encoding-algorithm>, or b) define a subset of = it >>>> that's simple yet precise. >>>=20 >>> I forgot who offered this text. It might have been either Tim or = Dick. >>>=20 >>> I received other suggested wording. I currently have this: >>>=20 > >>>=20 >>> Exactly what should we change? >>=20 >> ?? I reported an obvious bug and suggested three different ways to = fix >> it. What more do you want? >=20 > The text that is there was offered by somebody in order to try to make = it > clear as to how to present these parameters. Section 2.1 does not say = =3D or > & are or are not to be encoded, but merely says that "octet's = corresponding > character is outside the allowed set or is being used as a delimiter = of, or > within, the component" are encoded as explained in that section. When = the > text was proposed, I had no challenge understanding exactly what to = do. >=20 > So, this is why I'm having trouble understanding what to change. You = call it > an obvious bug, but it's not so obvious there is a bug to me. I would > prefer to not refer to the HTTP spec, as I think that is more = challenging to > read than either the other RFC or the text currently in the WF spec. = Not > sure how to address your concern. I referenced HTML, not HTTP. > Here's the current text: >=20 > ` This specification defines parameters that are passed from the = client to s/are/can be/ > the server when issuing a request. These parameters, "resource" and = "rel", > and the parameter values are included in the "query" component of the = URI > (see Section 3.4 of RFC 3986). To construct the "query" component, = the no scare quotes needed > client performs the following steps. First, each parameter value is > percent-encoded as per Section 2.1 of RFC 3986. This is the problem. "percent-encoded as per..." isn't specific enough, = because you're not saying *what* has to be encoded. Is it every = character? None? Every third one? You need to say, roughly: """ ...each parameter value is percent-encoded, as per Section 2.1 of RFC = 3986, so that conforms to the query production in Section 3.4 of that = specification, and additionally any instances of the "=3D" and "&" = characters are also percent-encoded. """ > Next, the client constructs > a string to be placed in the query component by concatenating the name = of > the first parameter together with an equal sign ("=3D") and the > percent-encoded parameter value. For any subsequent parameters, the = client > appends an ampersand ("&") to the string, the name of the next = parameter, an > equal sign, and the parameter value (percent-encoded as needed). Strike the parenthetical "percent-encoded as needed"; it's vague and = could be interepreted as requiring double-encoding. > The client > MUST NOT insert any spaces while constructing the string. The order = in > which the client places each attribute-and-value pair within the query > component is unspecified.' >=20 >>>> 4) Section 4.2 would be a lot clearer if you just said that the = well- >>>> known location is ONLY defined for the HTTPS URI scheme. >>>=20 >>> There are several things said in that section that are not related = to >> HTTPS. >>> Exactly what are you suggesting we change? >>=20 >> I think I'd change the top of Section 4 to be: >>=20 >> """ >> A Webfinger Resource is a well-known URI [ref] using the HTTPS = scheme. >> Webfinger resources MUST NOT be served with any other URI scheme = (such >> as HTTP). >>=20 >> GET requests to a WebFinger resource convey the URI to perform the = query >> upon in the URI's query string; see [ref to 4.1] for details. >> """ >>=20 >> Then, edit the rest of 4.x to fit with that. >=20 > That sounds good. How is this: >=20 > `A Webfinger resource is a well-known URI [3] using the HTTPS scheme. > Webfinger resources MUST NOT be served with any other URI scheme (such = as > HTTP). >=20 > GET requests to a WebFinger resource convey the URI to perform the = query > upon in the URI's query string; see Section 4.1 for details. >=20 > WebFinger returns a JSON Resource Descriptor (JRD) to convey = information > about an entity on the Internet and utilizes the Cross-Origin Resource > Sharing (CORS) [9] specification to facilitate queries made via a web > browser.' >=20 WFM. > The last paragraph switches from=20 >=20 >> BTW, what's the difference between 4.1 "Constructing a WebFinger = Query" >> and 4.2 "Performing a WebFinger Query"? Are these really two separate >> steps that justify their own subsections? >=20 > Section 4.1 is really about constructing the Request URI. Perhaps the = title > should be: >=20 > "Constructing a WebFinger Request URI" >=20 > Would that be better? Think so. >> Also, consider replacing "WebFinger server" with "WebFinger = Resource". >=20 > That might be doable, but I need to look through the whole document. = We use > "server" in a lot of places. We also use the word client a lot, as = the > terminology used has been client/server centric. So, I need to ensure = the > wording sounds right. I'm sure I'll mess that up ;-) >=20 > How do others feel about this one? >=20 >=20 >>>> 5) Why not define a media type for JRD? You can instruct clients to >>>> also accept application/json if you're worried about bad server >>>> configurations. >>>=20 >>> This was discussed separately. What's the point of an application >>> type for a JSON object that exists only in this context? There do = not >>> seem to be many people defining JSON-specific sub-types, either. >>> There are a gazillion >>> +xml registrations and it's a bit of a mess, IMO. >>=20 >> This is the Web; we identify formats with media types. How do you = know >> it's only ever going to "exist only in this context"? >=20 > A WF resource is an HTTP resource with a specific means defined of = accessing > the resource. If there ever was some other context, then it's not WF. >=20 > There are tons of web services out there using JSON today and they = don't all > have their own media types. IANA would be employed all day on that = problem > if folks did register every separate use of JSON. Absolutely. However, this is going to be an IETF-defined standard = format, for which you want interop and multiple implementations. There's = a huge difference between this and the JSON document that Bobby Sue = decides to slap up on the Web server. >>>> 6) What's the motivation for expires, given that HTTP caching >>>> information is already available? Have you considered the = interaction >>>> between them? >>>=20 >>> Expires is defined in XRD and the already-defined JRD in RFC 6415. >>=20 >> That's a really weak justification. This spec can choose to deprecate = it >> when used with WebFinger. What's it actually used for? Especially = since >> that, by definition, this protocol ONLY works over HTTP? >=20 > I have no use for it, but wanted to maintain compatibility with RFC = 6415 > since there are some folks who are using RFC 6415 and would appreciate = not > breaking the existing defined format. However, I don't know what = folks are > doing with it now. I don't send it from my own server. >=20 >>> There is >>> no discussion on the interaction between the HTTP caching and the = JRD >>> expires value. >>=20 >> Really? What happens when the HTTP response has a large freshness >> lifetime (either explicit or heuristic), but a smaller expires = window? >=20 > Then somebody has a bad implementation and a recipient is going to get = stale > data. >=20 >>> But, these are at two different layers in the stack. >>> Whatever generates a JRD may be a level removed from the HTTP = server. >>> Likewise on the receiving end that processes a JRD. >>=20 >> That's weak. You're happy to use the query string, so the server side >> will have access to HTTP headers. Very, VERY few clients these days >> don't have access to HTTP headers. >=20 > Well, it is. Consider the example where an email client performs a WF > query. It's not a web browser, but an email client. Perhaps this = email > client is configured to automatically query the WF server for a sender = as > soon as the message is opened. It might maintain JRDs for a while, = though, > since they're convenient data structures. There might be a hash map = on the > email address to JRD structures in memory. The email application = might > ignore the HTTP headers entirely and the "client" in this case is some = other > part of the client that displays pictures or other information it can > discover about a contact. The email client certainly could have = access to > the HTTP headers, but that might be a thread or two removed from the = other > code that is using the received JRD. >=20 > The same might be said on the server side. In fact, it's quite likely = even > more true. JRDs might be created or stored on some sixth server down = the > line somewhere far removed from the HTTP server responding to the = client > request. >=20 > There is even a more basic issue: what if the client and server clocks = are > different? Clients have to use some common sense. Let HTTP cache in > whatever way it does. If a JRD is expired, use it, but discard it. = It > might be expired due to caching or just because the client and server = clocks > are not aligned. Excellent point. HTTP's caching model takes clock drift into account. = Does yours? >>>> 7) Section 4.4.5 "user's preferred link relation." --> "user's >>>> preferred link relation type." (and likely elsewhere). >>>=20 >>> This is referring to multiple link relations of the same type. If >>> there are multiple link relations of the same type, the first one is >>> the user's preferred link relation. >>>=20 >>> That is, if I insert three link relations of type "avatar" into a = JRD, >>> the first one if my preferred avatar. >>=20 >> Hmm. In that case, it would just be "links" not "link relations". >=20 > OK >=20 >>>> 8) RFC5988 defines the "target IRI" as what's at the end of the = link; >>>> here, "linked resource" is used (e.g., 4.4.5.[2,3]). Suggest = "target >>>> resource" as a way to tie them together conceptually. >>>=20 >>> Just replace "linked resource" with "target resource"? >>=20 >> Yes. >=20 > Done. >=20 >>>> 9) Similarly, an important concept in 5988 is the "context" of the >>>> link; suggest saying that the context of all of these links is the >> subject(s). >>>=20 >>> Can you suggest words to add? >>=20 >> At the top of 4.4.5: >>=20 >> """ >> The "links" array has any number of member objects, each of which >> represents a link [RFC5988]. Each of these link objects can have the >> following members: >>=20 >> * rel >> * type >> * href >> * titles >> * properties >>=20 >> The "rel" and "href" members are strings representing the link's >> relation type and the target IRI, respectively. The context of the = link >> is the subject [ref to subject]. >>=20 >> The "type" member is a string indicating what the media type of the >> result of dereferencing the link ought to be. >> """ >=20 > OK.. I added that text. >=20 >> BTW, 4.4.5 uses "elements" several times. JSON doesn't have elements; >> the only containment relationships are object members and array = members. >=20 > Arrays have "elements". Presently, there is only one use of the word > "elements" in 4.4.5 now and it is in reference to the things in the = links > array. So, I think it's OK. OK, my bad. >>>> 10) What if a target resource supports multiple media types for the >>>> same relation? Suggest allowing multiple values in "type." >>>=20 >>> This would require a change in the syntax, which I'd rather not do = at >>> this point. However, this can be accomplished by defining two array >>> elements, both having the same "rel" value, but having a different >> "type" value. >>=20 >> I'd like to hear the WG response in addition to the editors' = response. >=20 > Buried in here? :) I might be the only one reading this deep. LOL > Do feel free > to raise it up if you want, but we did go down the path of changing = the > syntax and such. I don't think this particular issue was raised = before, > though. Well, I *hope* the WG chairs are paying attention, given that this is = WGLC feedback, and they'll do the right thing. Let's see.. > Is this legal in the Web Linking spec? It appears the ABNF would = allow for > multiple "type" parameters, but I've never seen that. The contents of = a > type parameter, though, appears to be a single type. Perhaps I'm = misreading > that at this late hour. It's probably best described as "possible, yet (or perhaps because it's) = ill-defined." That having been said, that's only the HTTP header serialisation (which = was pre-defined before 5988). The model for linking defined by 5988 = doesn't have any such constraints. Effectively, you're defining a new = serialisation of that model. >>>> 11) 4.5 says "WebFinger requests can include a parameter >> specifying..." >>>> What kind of parameter? Tie it back to what happens in 4.1. >>>=20 >>> This is just the "resource" parameter. Perhaps it's clearer if >>> written this >>> way: >>>=20 >>> 'WebFinger requests can include a "resource" parameter = specifying...' >>=20 >> The core problem is that "parameter" is not well-defined in this >> specification. See earlier feedback. >=20 > OK. I think the recent changes made to 4.1 will make that clearer. > Obviously, it's hard for me to see that what I wrote is not clear in = someone > else's mind. ;-) >=20 >>>> 14) In section 7 (and likely elsewhere), you should use the full = URL, >>>> not just the path /.well-known/webfinger, to make it clear that = this >>>> is just over HTTPS. >>>=20 >>> Are you referring to the examples? >>=20 >> Yes. >=20 > I got rid of those entirely yesterday, so they ought not be an issue. >=20 >>> That is what the protocol would look >>> like on the wire. If you're referring to the text like this: >>>=20 >>> 'When a query is issued to "/.well-known/webfinger", the web >> server...' >>>=20 >>> The challenge there is that I need a hostname and I would not want = to >>> put "example.com" there. Perhaps it might be better to just say: >>>=20 >>> 'When a query is issued to the WebFinger resource, the web = server...' >>>=20 >>> But, that would not help clarify the use of HTTPS. But, use of = HTTPS >>> is stated so many times in the doc, I don't think people will screw >> that up. >>=20 >> That could work. An alternative would be >>=20 >> "When a query is issued to the "/.well-known/webfinger" resource on = an >> HTTPS Web server..." >>=20 >> However, I think I like your formulation better, provided that >> "webfinger resource" is well-defined (see above). >=20 > "resource" is OK, but we also have "WebFinger location" and "server" = in > different places. I like consistent terminology, but this is a = "well-known > location" that happens to be a REST "resource" that works like a > client/server protocol. Makes my head hurt. +1 on consistency being the high-order bit. -- Mark Nottingham http://www.mnot.net/ From paulej@packetizer.com Thu Feb 7 12:28:52 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 0FC6B21F8896 for ; Thu, 7 Feb 2013 12:28:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DjXVjB4ckbPd for ; Thu, 7 Feb 2013 12:28:51 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 161B621F8895 for ; Thu, 7 Feb 2013 12:28:51 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r17KSnpi010225 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Feb 2013 15:28:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1360268930; bh=zcxsoZLC/uOh/jEwTn7l+wtiFHjkxpiIgsfQsgiblQU=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; b=e1ji4EYru+tazcwN6qckisz01ukoWBUtHplwZBsqyikw1ASFavokk+8Ke6ZPSXaRN BVd01WDLMLvqYnnDJwtfBFd3pvEBDY0J9HBpGN3otWO6H6hVa2WzSYmo18vJLrARVL acE+T5wnFM8IbUqOV26T6lkUZqJNkC5wpfdE3g+4= From: "Paul E. Jones" To: , Date: Thu, 7 Feb 2013 15:28:59 -0500 Message-ID: <006601ce0571$c2b9c180$482d4480$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0067_01CE0547.D9E407A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4FcYIMOfmxZ3J+RmCz066Z8WbK1Q== Content-Language: en-us Subject: [webfinger] The "expires" member of the JRD 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, 07 Feb 2013 20:28:52 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0067_01CE0547.D9E407A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Folks, Questions have been raised about the "expires" member of the JRD two or three times now, with concerns related to the fact that HTTP has multiple ways of also indicating how long a resource representation should be cached. This element is exists for historical reason, but it's not clear to me if anyone is using it or cares to use it. Shall we keep it or just remove it from the spec entirely? Paul ------=_NextPart_000_0067_01CE0547.D9E407A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

Questions = have been raised about the “expires” member of the JRD two = or three times now, with concerns related to the fact that HTTP has = multiple ways of also indicating how long a resource representation = should be cached.

 

This element = is exists for historical reason, but it’s not clear to me if = anyone is using it or cares to use it.

 

Shall we = keep it or just remove it from the spec entirely?

 

Paul

 

------=_NextPart_000_0067_01CE0547.D9E407A0-- From bradfitz@google.com Thu Feb 7 12:35: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 038E021F8635 for ; Thu, 7 Feb 2013 12:35:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.726 X-Spam-Level: X-Spam-Status: No, score=-102.726 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jhW-SMeMsKSS for ; Thu, 7 Feb 2013 12:35:17 -0800 (PST) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5524A21F8599 for ; Thu, 7 Feb 2013 12:35:17 -0800 (PST) Received: by mail-qa0-f51.google.com with SMTP id cr7so24554qab.3 for ; Thu, 07 Feb 2013 12:35:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=AM74TuO7FfMnvBs4FGfi21F39s5e6vqk+7zIeaMyQFE=; b=QV3rOo7za3tWGTfJD8xj6tLH80ryfh1MQQsDu2ZS6mxjQbnY+CRk8owf65j8sj3Hc5 Y1b1N8gywDMIe/UaXg6YP4+Lfnq5NI+jwU27Q8q8PCP+HjzPc0sdWbE/y7443MyRvwCm 3PIEFi5RqIhScjBieKpC/9jtwY9Xr9Y+zl1yv0iDPesUrWQjdJQdoj9n0+sxo5UGLFhN gsK1BxVUcwHnjIhuBzbxZWujazlq+mgMbH17tHQ2A4HqTKw6v2q07/50Duy/tQWeWc2Q JAlIUc/xHTDKabciXCpvhEiXWuRFoOHC/WeXDfkHx5wAuZR3fD/kalNoL4CKA6/VDbfU 5vUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=AM74TuO7FfMnvBs4FGfi21F39s5e6vqk+7zIeaMyQFE=; b=YDRcKd6v+fbqrP+gFdTh9rHsyHC7H7adjFeH07f9lF7NJmLS8x3XHab8CO8UnUYCBW LCQSO/IzoWss+hAZCMbZa0fs7UC+4ODLgCRO4dhWkymPa1FYulX+yQMlO8ZJHYYjgWYH pGCJgb9jsn3t2BYqi8f1SksPZHt9eMC1M4vnHzGN+m0L2j7hNdVboVEeMafBFAvou/oC YGMmfdmMFh1qnrycBZGjzSUarsbboJeefT9SQ1aWOINuPeJZC0HYC10bjCzMLY/jBuKM eUhDlmfu555ZhNLAq/lRfTwuW4NnowzXuIoQcugVpF9mXC7n+Lhjq637uyo4b+E4cbNU cmMA== MIME-Version: 1.0 X-Received: by 10.224.193.202 with SMTP id dv10mr1206341qab.77.1360269314775; Thu, 07 Feb 2013 12:35:14 -0800 (PST) Received: by 10.224.33.203 with HTTP; Thu, 7 Feb 2013 12:35:14 -0800 (PST) In-Reply-To: <006601ce0571$c2b9c180$482d4480$@packetizer.com> References: <006601ce0571$c2b9c180$482d4480$@packetizer.com> Date: Thu, 7 Feb 2013 12:35:14 -0800 Message-ID: From: Brad Fitzpatrick To: "webfinger@googlegroups.com" Content-Type: multipart/alternative; boundary=20cf300fb4b34e5abe04d5286123 X-Gm-Message-State: ALoCoQnjGPWdjed7YCYcbLsIE9/4cS8v9cboGGg8zEsBFhkSMD2/7qrvvjZMVXSFPrGwVow9wKtpglJki/QOr0SO5t7xHqh6PMHQHXbw17v0sZLCE7FMudey+c/PhIhh0ImQzPlabLWr9PSP/uu5fpZrtqYfeixTivP/f2eULGgmH88yyD8eN9YcVqPv4hQMlMjjImO6hpbj Cc: "webfinger@ietf.org" Subject: Re: [webfinger] The "expires" member of the JRD 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, 07 Feb 2013 20:35:18 -0000 --20cf300fb4b34e5abe04d5286123 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'd be happy seeing it removed. HTTP seems sufficient. On Thu, Feb 7, 2013 at 12:28 PM, Paul E. Jones wrote= : > Folks,**** > > ** ** > > Questions have been raised about the =E2=80=9Cexpires=E2=80=9D member of = the JRD two or > three times now, with concerns related to the fact that HTTP has multiple > ways of also indicating how long a resource representation should be cach= ed. > **** > > ** ** > > This element is exists for historical reason, but it=E2=80=99s not clear = to me if > anyone is using it or cares to use it.**** > > ** ** > > Shall we keep it or just remove it from the spec entirely?**** > > ** ** > > Paul**** > > ** ** > > -- > > --- > You received this message because you are subscribed to the Google Groups > "WebFinger" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to webfinger+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > --20cf300fb4b34e5abe04d5286123 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'd be happy seeing it removed.

HTTP seems sufficient.



On Thu, Feb 7, 2013 at 12:28 P= M, Paul E. Jones <paulej@packetizer.com> wrote:

Folks,

=C2=A0

Questions have been raised about the =E2=80=9Cexpire= s=E2=80=9D member of the JRD two or three times now, with concerns related = to the fact that HTTP has multiple ways of also indicating how long a resou= rce representation should be cached.

=C2=A0

This = element is exists for historical reason, but it=E2=80=99s not clear to me i= f anyone is using it or cares to use it.

=C2=A0

Shall we keep it or just remove it from the spec ent= irely?<= /span>

=C2=A0

Paul

= =C2=A0

--
=C2=A0
---
You received this message because you are subscribed to the Google Groups &= quot;WebFinger" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to webfinger+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
=C2=A0
=C2=A0

--20cf300fb4b34e5abe04d5286123-- From gsalguei@cisco.com Thu Feb 7 12:36:07 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 892E221F8635 for ; Thu, 7 Feb 2013 12:36:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.507 X-Spam-Level: X-Spam-Status: No, score=-10.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWYbZWzbihYC for ; Thu, 7 Feb 2013 12:36:07 -0800 (PST) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 0105F21F89CE for ; Thu, 7 Feb 2013 12:36:06 -0800 (PST) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r17Ka6NE024674 for ; Thu, 7 Feb 2013 15:36:06 -0500 (EST) Received: from dhcp-64-102-154-246.cisco.com (dhcp-64-102-154-246.cisco.com [64.102.154.246]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r17Ka6De007264; Thu, 7 Feb 2013 15:36:06 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Gonzalo Salgueiro In-Reply-To: Date: Thu, 7 Feb 2013 15:36:06 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <006601ce0571$c2b9c180$482d4480$@packetizer.com> To: Brad Fitzpatrick X-Mailer: Apple Mail (2.1499) Cc: webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] The "expires" member of the JRD 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, 07 Feb 2013 20:36:07 -0000 +1 Gonzalo On Feb 7, 2013, at 3:35 PM, Brad Fitzpatrick = wrote: > I'd be happy seeing it removed. >=20 > HTTP seems sufficient. >=20 >=20 >=20 > On Thu, Feb 7, 2013 at 12:28 PM, Paul E. Jones = wrote: > Folks, >=20 > =20 >=20 > Questions have been raised about the =93expires=94 member of the JRD = two or three times now, with concerns related to the fact that HTTP has = multiple ways of also indicating how long a resource representation = should be cached. >=20 > =20 >=20 > This element is exists for historical reason, but it=92s not clear to = me if anyone is using it or cares to use it. >=20 > =20 >=20 > Shall we keep it or just remove it from the spec entirely? >=20 > =20 >=20 > Paul >=20 > =20 >=20 >=20 > --=20 > =20 > ---=20 > You received this message because you are subscribed to the Google = Groups "WebFinger" group. > To unsubscribe from this group and stop receiving emails from it, send = an email to webfinger+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > =20 > =20 >=20 > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger From paulej@packetizer.com Thu Feb 7 12:48: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 27CD721F854D for ; Thu, 7 Feb 2013 12:48:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NuJBdumq6s5B for ; Thu, 7 Feb 2013 12:48:10 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id DAE3221F8546 for ; Thu, 7 Feb 2013 12:48:09 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r17Km5Bb012040 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Feb 2013 15:48:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1360270085; bh=41kCI+s69w3vp/3Sbbn9/HFmUwWdZHCrxlV4ImpCmLA=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; b=pR11USMst0bt2EAV0JYDFPwAono5/7bYY2jPL8qJh66o+dwJbIzjt57NSPb1fE5AV zwkF/xUGmYZbfMM/5Wb/TOQV6dE4r7n5vESV7St6/arVAC+1HHCJM/+wd5CprlA17z Pb/rlg/W9Ib6BcpDLT/VJUjfoSy+GG9LhARj3eeA= From: "Paul E. Jones" To: , Date: Thu, 7 Feb 2013 15:48:14 -0500 Message-ID: <008801ce0574$7373d7c0$5a5b8740$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0089_01CE054A.8A9E44F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4Fc+OnNsp5F4zbTTKegp3x/gh3yw== Content-Language: en-us Subject: [webfinger] Renaming the "resource" parameter 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, 07 Feb 2013 20:48:11 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0089_01CE054A.8A9E44F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Folks, In the most recent round of edits (I hope to publish tomorrow) I made a pass through the text to try to use the word "resource" or "WebFinger resource" rather than "WebFinger server" where it made sense. ("Server" is still used, but hopefully only when speaking of the web server itself.) But, as I did that, I noticed that in at least one place the word "resource" (referring to the parameter that gets passed in) seemed to make the text confusing. I put quotes around "resource" when I'm referring to the parameter. The question is this: should we rename the "resource" parameter to something else? SWD used "principal" and the JRD uses the term "subject". I think either of those would work as alternatives. Or, shall we continue with "resource"? I think it's worded so that it's not confusing now, but I'm probably a poor judge of that since I know is meant. Paul ------=_NextPart_000_0089_01CE054A.8A9E44F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

In the most = recent round of edits (I hope to publish tomorrow) I made a pass through = the text to try to use the word “resource” or = “WebFinger resource” rather than “WebFinger = server” where it made sense.  (“Server” is still = used, but hopefully only when speaking of the web server = itself.)

 

But, as I did that, I noticed that in at least one = place the word “resource” (referring to the parameter that = gets passed in) seemed to make the text confusing.  I put quotes = around “resource” when I’m referring to the = parameter.

 

The question is this: should we rename the = “resource” parameter to something else?

 

SWD used = “principal” and the JRD uses the term = “subject”.  I think either of those would work as = alternatives.

 

Or, shall we continue with = “resource”?  I think it’s worded so that = it’s not confusing now, but I’m probably a poor judge of = that since I know is meant.

 

Paul

 

------=_NextPart_000_0089_01CE054A.8A9E44F0-- From paulej@packetizer.com Thu Feb 7 12:48:24 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 767E821F8910 for ; Thu, 7 Feb 2013 12:48:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqq3Wmwv1LSn for ; Thu, 7 Feb 2013 12:48:23 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 3723821F8546 for ; Thu, 7 Feb 2013 12:48:23 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r17KmM4b012089 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Feb 2013 15:48:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1360270102; bh=vFhcaDL0MBP4ITpYmC4cP5FVryI1PKZgITvJctVDlpU=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=bCtLdRYnVssCX9yIu51dzfz8R+rMbRpHW8oz1jKOM1m1gw1TwW1QbepMl/gcQ6+ab yS//9kCRqPya2u19t1FXZ3hFTfdkjF6wkIA5PNqyQbliY3DmZVfALGuk5+KLO/RdWe NU0dserkAZL/hEkF56sqPE0t6iX0XutJKZA+ioF0= From: "Paul E. Jones" To: "'Mark Nottingham'" References: <046e01ce0437$43df8ec0$cb9eac40$@packetizer.com> <076a01ce050d$b0a8f6a0$11fae3e0$@packetizer.com> <18645BD5-3F95-4EAC-8693-219539257FA5@mnot.net> In-Reply-To: <18645BD5-3F95-4EAC-8693-219539257FA5@mnot.net> Date: Thu, 7 Feb 2013 15:48:31 -0500 Message-ID: <009501ce0574$7da4ca60$78ee5f20$@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: AQK/nJvLr+z8azcZ5q9IuXWd/66KiwIIYIiqAvf8rVoCRNow1wEkBAIXlkguMMA= Content-Language: en-us Cc: webfinger@ietf.org Subject: Re: [webfinger] [apps-discuss] WGLC feedback on webfinger-09 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, 07 Feb 2013 20:48:24 -0000 Mark, > >> """ > >> WebFinger is a protocol for locating information about various types > >> of URIs that might not be usable as a locator otherwise. For example, > >> mailto: and acct: URIs can be used to identify e-mail and localised > >> accounts, but they do not provide an in-built way to discover and > >> convey additional information about the identifier. > >> > >> WebFinger builds on top of HTTP [ref], TLS [ref], JSON [ref] and Web > >> Linking [ref] to provide this service, through a well-known [ref] > >> HTTPS URI on the same host as the URI's authority. Note that > >> WebFinger cannot be used to find information about URIs that do not > >> have an authority (e.g., URNs). > >> """ > >> > > Perhaps. Your turn :) I'd prefer to leave the intro alone, since we do cover every point you made, I think. To address your initial point by modifying the abstract to read: 'This specification defines the WebFinger protocol, which can be used to discover information about people or other entities on the Internet using standard HTTP methods. WebFinger discovers information for a URI that might not be usable as a locator otherwise, such as account or email URIs.' I welcome suggested changes, but I do like to use the word "discover" since that means something to the human reader that is different than "locate". Indeed, we're not just "locating" information. A client does not necessarily know what I am publishing via WF, so it truly is a "discovery" process. > >>>> 2) The examples use unregistered link relations types > >>>> > >>>> ; specifically, "blog" and "vcard". Naughty. > >>> > >>> Yeah, but there is an intent to register both of those. You're the > >>> expert > >>> here: any reason these could not be registered for their intended > >> purposes? > >>> (We can use URIs here, but the group preferred to use these type > >>> names.) > >> > >> Putting unregistered ANYTHING in an RFC is bad -- especially if it > >> looks vaguely useful. > > > > OK, I can change them. I'm not sure what to change them to, though. > > I guess another URI. I'd like to have at least one example that is > not a URI. > > Perhaps I should replace one of those with something already > registered. > > I'll have to ponder this one. (Comments, anyone?) > > > >> Register them or change them, before publishing. Since "text/vcard" > >> is already a media type, you might want to re-think that one before > >> doing so; it's likely to have problems as-is. > > > > Why would that present an issue? That's a different registry. > > Right, but part of the guidance about what's appropriate as a link > relation is that it's *not* format-specific. Oh, I understand now. I'll change it to this URI: http://webfinger.example/rel/businesscard I'll do the same for "blog". (relating to section 4.1): > > So, this is why I'm having trouble understanding what to change. You > > call it an obvious bug, but it's not so obvious there is a bug to me. > > I would prefer to not refer to the HTTP spec, as I think that is more > > challenging to read than either the other RFC or the text currently in > > the WF spec. Not sure how to address your concern. > > I referenced HTML, not HTTP. Sorry... typo at 3am ;-) > > Here's the current text: > > > > ` This specification defines parameters that are passed from the > > client to > > s/are/can be/ OK > > the server when issuing a request. These parameters, "resource" and > > "rel", and the parameter values are included in the "query" component > > of the URI (see Section 3.4 of RFC 3986). To construct the "query" > > component, the > > no scare quotes needed I assume that's just around "query". I do prefer to keep them around "resource" and "rel" since those are being first formally introduced in this section. > > client performs the following steps. First, each parameter value is > > percent-encoded as per Section 2.1 of RFC 3986. > > This is the problem. "percent-encoded as per..." isn't specific enough, > because you're not saying *what* has to be encoded. Is it every > character? None? Every third one? > > You need to say, roughly: > > """ > ...each parameter value is percent-encoded, as per Section 2.1 of RFC > 3986, so that conforms to the query production in Section 3.4 of that > specification, and additionally any instances of the "=" and "&" > characters are also percent-encoded. > """ Good. I'll introduce that language. > > Next, the client constructs > > a string to be placed in the query component by concatenating the name > > of the first parameter together with an equal sign ("=") and the > > percent-encoded parameter value. For any subsequent parameters, the > > client appends an ampersand ("&") to the string, the name of the next > > parameter, an equal sign, and the parameter value (percent-encoded as > needed). > > Strike the parenthetical "percent-encoded as needed"; it's vague and > could be interepreted as requiring double-encoding. OK, done. > >> Also, consider replacing "WebFinger server" with "WebFinger Resource". > > > > That might be doable, but I need to look through the whole document. > > We use "server" in a lot of places. We also use the word client a > > lot, as the terminology used has been client/server centric. So, I > > need to ensure the wording sounds right. I'm sure I'll mess that up > > ;-) > > > > How do others feel about this one? > > I changed the text to refer to "webfinger resource" or "resource". Server is used sparingly and I tried to use it only when referring to functions provided by the web server. > > There are tons of web services out there using JSON today and they > > don't all have their own media types. IANA would be employed all day > > on that problem if folks did register every separate use of JSON. > > Absolutely. However, this is going to be an IETF-defined standard format, > for which you want interop and multiple implementations. There's a huge > difference between this and the JSON document that Bobby Sue decides to > slap up on the Web server. If we were to take the JRD format and use it elsewhere other than WebFinger AND we would use that in a place where there might be alternative JSON formats, I agree. It's just not clear to me we would ever do that. > >>>> 6) What's the motivation for expires, given that HTTP caching > >>>> information is already available? Have you considered the > >>>> interaction between them? ... > > There is even a more basic issue: what if the client and server clocks > > are different? Clients have to use some common sense. Let HTTP cache > > in whatever way it does. If a JRD is expired, use it, but discard it. > > It might be expired due to caching or just because the client and > > server clocks are not aligned. > > Excellent point. HTTP's caching model takes clock drift into account. > Does yours? First, be mindful that this is not mine. :-) I'm just elaborating on what has been defined already. I do not understand how an HTTP client (browser or caching server) can accommodate for clock differences. If the client and server think the time is 15 minutes apart, then the timestamps are wrong for one or the other or both. Of course, using the "max-age" parameter helps, as time is not given in absolute terms. Clock drift and merely having the wrong time are two different issues, too. We deal with clock drift in NTP and real-time communications, but caching servers do? I'm confused. In any case, the simplest solution is to ensure that the HTTP headers align with the "Expires" value in the JRD. Perhaps nobody even cares about the "expires" member. I'll ask separately if we should just remove it. (related to multiple values in the "type" parameter)... > > Is this legal in the Web Linking spec? It appears the ABNF would > > allow for multiple "type" parameters, but I've never seen that. The > > contents of a type parameter, though, appears to be a single type. > > Perhaps I'm misreading that at this late hour. > > It's probably best described as "possible, yet (or perhaps because it's) > ill-defined." > > That having been said, that's only the HTTP header serialisation (which > was pre-defined before 5988). The model for linking defined by 5988 > doesn't have any such constraints. Effectively, you're defining a new > serialisation of that model. Honestly, I never gathered that from 5988 before. RFC 5988 even says: 'The "type" parameter, when present, is a hint indicating what the media type of the result of dereferencing the link should be.' It sounds very singular to me. If we were to allow multiple types, they would either have to be space-separated or we would have to change "type" to an array. I suspect there would be resistence to that, especially since "type" is merely a hint w.r.t. the media type that will be returned. >>> But, that would not help clarify the use of HTTPS. But, use of > >>> HTTPS is stated so many times in the doc, I don't think people will > >>> screw > >> that up. > >> > >> That could work. An alternative would be > >> > >> "When a query is issued to the "/.well-known/webfinger" resource on > >> an HTTPS Web server..." > >> > >> However, I think I like your formulation better, provided that > >> "webfinger resource" is well-defined (see above). > > > > "resource" is OK, but we also have "WebFinger location" and "server" > > in different places. I like consistent terminology, but this is a > > "well-known location" that happens to be a REST "resource" that works > > like a client/server protocol. Makes my head hurt. > > +1 on consistency being the high-order bit. I've made an effort to do that. Now, though, I don't like the parameter name "resource". Where it appears in prose, I put quotes around it so people are not confused with the WebFinger resource. I think SWD called this "principal". Since JRD uses the term "subject", perhaps we should rename the "resource" parameter to "subject". Usually, the "subject" passed in will be the "subject" returned, though not always. In any case, I hate having the same word used two times to mean something entirely different. I raise that question to the list, too. Not sure anybody scrolled this far. Paul From tbray@textuality.com Thu Feb 7 12:52:23 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 05BC621F8648 for ; Thu, 7 Feb 2013 12:52:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.727 X-Spam-Level: X-Spam-Status: No, score=-4.727 tagged_above=-999 required=5 tests=[AWL=-1.751, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p0uQvnfZV8iy for ; Thu, 7 Feb 2013 12:52:22 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 530FB21F856F for ; Thu, 7 Feb 2013 12:52:22 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id h1so3343069oag.31 for ; Thu, 07 Feb 2013 12:52:22 -0800 (PST) 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=RbTLnbQUAsCej6zxZwZq3tMux9ACNukxBbhRcXFCIqs=; b=fJBECGe/EywP1YmU7lwwiTgAF0w9/Fpn+6FrzgC7HvPlvfqsc1kXByscGemvgFZBtS ncLHJ/V+ByNkGNiDClRRl9pZSf+olLNpmD/gxQ1qma9oKlAnEmSUcnJtSZVWKP64bHPk 3N/Q4UNiq3a6Qh9g4J1/bUPUYFGJJy0GC7Eg2QGfCYM6QwX0z77T/d3sM9gNPXewLFxW tFS44HTw+l3TksfBZLeMBq3KHCPY67EH3CnMnxFM9AmoeCW/+lmhIGoe+mpd3kCaZJkc dZiANEqlADYqExQ+PDb2HrJY7vzR9fx10pfqDN3EqeodnUC5IN0Z2L2uqECz+XpMA5Xf /c/g== MIME-Version: 1.0 X-Received: by 10.182.98.5 with SMTP id ee5mr2347283obb.28.1360270341942; Thu, 07 Feb 2013 12:52:21 -0800 (PST) Received: by 10.76.173.38 with HTTP; Thu, 7 Feb 2013 12:52:21 -0800 (PST) X-Originating-IP: [96.49.72.110] In-Reply-To: References: <006601ce0571$c2b9c180$482d4480$@packetizer.com> Date: Thu, 7 Feb 2013 12:52:21 -0800 Message-ID: From: Tim Bray To: Brad Fitzpatrick Content-Type: multipart/alternative; boundary=14dae93a125787af0e04d5289e69 X-Gm-Message-State: ALoCoQlRhTup22+HaL47zLPznlsgjsmP1zhQv432/PYmvjXFU5TgqDNnXCwFnZyl7pBypwi2x8py Cc: "webfinger@ietf.org" , "webfinger@googlegroups.com" Subject: Re: [webfinger] The "expires" member of the JRD 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, 07 Feb 2013 20:52:23 -0000 --14dae93a125787af0e04d5289e69 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable +1 On Thu, Feb 7, 2013 at 12:35 PM, Brad Fitzpatrick wrot= e: > I'd be happy seeing it removed. > > HTTP seems sufficient. > > > > On Thu, Feb 7, 2013 at 12:28 PM, Paul E. Jones wro= te: > >> Folks,**** >> >> ** ** >> >> Questions have been raised about the =93expires=94 member of the JRD two= or >> three times now, with concerns related to the fact that HTTP has multipl= e >> ways of also indicating how long a resource representation should be cac= hed. >> **** >> >> ** ** >> >> This element is exists for historical reason, but it=92s not clear to me= if >> anyone is using it or cares to use it.**** >> >> ** ** >> >> Shall we keep it or just remove it from the spec entirely?**** >> >> ** ** >> >> Paul**** >> >> ** ** >> >> -- >> >> --- >> You received this message because you are subscribed to the Google Group= s >> "WebFinger" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n >> email to webfinger+unsubscribe@googlegroups.com. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > > --14dae93a125787af0e04d5289e69 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
+1
 --14dae93a125787af0e04d5289e69-- From tbray@textuality.com Thu Feb 7 12:53: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 386BE21F86EF for ; Thu, 7 Feb 2013 12:53:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.143 X-Spam-Level: X-Spam-Status: No, score=-4.143 tagged_above=-999 required=5 tests=[AWL=-1.167, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IKQRFUn1j2+U for ; Thu, 7 Feb 2013 12:53:13 -0800 (PST) Received: from mail-oa0-f46.google.com (mail-oa0-f46.google.com [209.85.219.46]) by ietfa.amsl.com (Postfix) with ESMTP id 4768721F8936 for ; Thu, 7 Feb 2013 12:53:11 -0800 (PST) Received: by mail-oa0-f46.google.com with SMTP id k1so3306109oag.19 for ; Thu, 07 Feb 2013 12:53:09 -0800 (PST) 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=dkXwtpFjYEbl5lJAuWvmOqLlnxBExZr9K6Jf41qIqMA=; b=Q1/XJoDikufo5WhMwk0mmrKWD6QmcZatNFi4gPZUYLZ5b8Z+PRc4Wp1NWzW5a0Pr/8 N4QNN+RN59j7CKHS5EJM91Rsnkg1aNCIo157ORmApxHeMzGNZoSJjBwZHz6tdn0PDKLL KXQONdzDL28T3Gr8S4Uh+An/T2ySuVYDIY3iAKmcjbpjzOiECKYwTxWdOyIp8dc2SAg2 7RtjtdRpiEbnLx8U9jQQ/X4ieKZa8qQPj4DYtb497QIxyCjwYY00RI9a+qIZ6iWX2cgC c7RxvK9sdGKb9/2ZQVZt2sJGChMxmfA7GbFbrdPRvGvBcuI/EO6//+9IGoWNZ0rlH1/H dZNw== MIME-Version: 1.0 X-Received: by 10.60.22.169 with SMTP id e9mr2266312oef.70.1360270389443; Thu, 07 Feb 2013 12:53:09 -0800 (PST) Received: by 10.76.173.38 with HTTP; Thu, 7 Feb 2013 12:53:09 -0800 (PST) X-Originating-IP: [96.49.72.110] In-Reply-To: <008801ce0574$7373d7c0$5a5b8740$@packetizer.com> References: <008801ce0574$7373d7c0$5a5b8740$@packetizer.com> Date: Thu, 7 Feb 2013 12:53:09 -0800 Message-ID: From: Tim Bray To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=e89a8fb1ee1a5c7c0404d528a1ba X-Gm-Message-State: ALoCoQntD7zl9RLKxLOzVDmqpfL/cPqgoSYxUpIfz1sDb4t1mp0Igbomdeylpw2h6Y6W0sB+tVjc Cc: "webfinger@ietf.org" , "webfinger@googlegroups.com" Subject: Re: [webfinger] Renaming the "resource" parameter 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, 07 Feb 2013 20:53:24 -0000 --e89a8fb1ee1a5c7c0404d528a1ba Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable =93resource=94 is fine. -T On Thu, Feb 7, 2013 at 12:48 PM, Paul E. Jones wrote= : > Folks,**** > > ** ** > > In the most recent round of edits (I hope to publish tomorrow) I made a > pass through the text to try to use the word =93resource=94 or =93WebFing= er > resource=94 rather than =93WebFinger server=94 where it made sense. (=93= Server=94 is > still used, but hopefully only when speaking of the web server itself.)**= * > * > > ** ** > > But, as I did that, I noticed that in at least one place the word > =93resource=94 (referring to the parameter that gets passed in) seemed to= make > the text confusing. I put quotes around =93resource=94 when I=92m referr= ing to > the parameter.**** > > ** ** > > The question is this: should we rename the =93resource=94 parameter to > something else?**** > > ** ** > > SWD used =93principal=94 and the JRD uses the term =93subject=94. I thin= k either > of those would work as alternatives.**** > > ** ** > > Or, shall we continue with =93resource=94? I think it=92s worded so that= it=92s > not confusing now, but I=92m probably a poor judge of that since I know i= s > meant.**** > > ** ** > > Paul**** > > ** ** > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > > --e89a8fb1ee1a5c7c0404d528a1ba Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
=93resource=94 is fine. -T


On Thu, Feb 7, 2013 at 12:48 PM, Pa= ul E. Jones <paulej@packetizer.com> wrote:

Folks,

=A0

In the most recent round of edits (I hope to publish= tomorrow) I made a pass through the text to try to use the word =93resourc= e=94 or =93WebFinger resource=94 rather than =93WebFinger server=94 where i= t made sense.=A0 (=93Server=94 is still used, but hopefully only when speak= ing of the web server itself.)

=A0

But, as = I did that, I noticed that in at least one place the word =93resource=94 (r= eferring to the parameter that gets passed in) seemed to make the text conf= using. =A0I put quotes around =93resource=94 when I=92m referring to the pa= rameter.

=A0

The ques= tion is this: should we rename the =93resource=94 parameter to something el= se?

=A0

SWD used =93principal=94 and the JRD uses the term =93subject=94.=A0 I thin= k either of those would work as alternatives.

=A0

Or, shall we continu= e with =93resource=94?=A0 I think it=92s worded so that it=92s not confusin= g now, but I=92m probably a poor judge of that since I know is meant.

=A0

Paul

=A0


_______________= ________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger


--e89a8fb1ee1a5c7c0404d528a1ba-- From bradfitz@google.com Thu Feb 7 12:53:24 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 3EBC121F8B49 for ; Thu, 7 Feb 2013 12:53:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.809 X-Spam-Level: X-Spam-Status: No, score=-102.809 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i8o7sBQpOjzz for ; Thu, 7 Feb 2013 12:53:14 -0800 (PST) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id D45A021F8A8B for ; Thu, 7 Feb 2013 12:53:12 -0800 (PST) Received: by mail-wi0-f179.google.com with SMTP id ez12so75406wid.6 for ; Thu, 07 Feb 2013 12:53:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=tCGfHzXMzkVk0A/UooTjvfp9ZBSTyBrn/FIKSP4i4Hw=; b=EubzWLlU7praDRQXo1cuv6kidrTIaJuF2b+X6QlKk1hsQQtXTIc7jWseIDrQtZ1KbE da4FxP7ZWxte11OCXfMl238l5T+jLqLnZbpsaJCM4lIwsYSRMNphmcny3rc7UcZX6Elw mwPQFGrztkVdvtANtuRqP7AlJ4j07HjHOOd0AlsJI+/5PVEbQbTlTenHLX+fNQEujkie yEzqbwmpsMeOGR/5bIA/juEjqDNtRFF9MwAzlbxzl5lHSSQ3yDlDW0kxg1VRlkgPzD1B 7EVT4gubugFdk1hsFjxxCcFP1URFM1bquYZc1bsLIiYjHGkF8PFMwlx41SjsxgmqOdVe hIgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=tCGfHzXMzkVk0A/UooTjvfp9ZBSTyBrn/FIKSP4i4Hw=; b=M0xIcwYZk+bQNEqDlh3INglrf+agoCkaMRtOQXTJA6GoyOE96rH2IvCfMU5XIOx9xJ mx/MU3YpXNcqAIvrPZdTsIbBeqXLtwAVLzgQYlsxZ5UUqg+q3UjmW3jg+gmPgY0eZlwt K21XJtV20FPTVyiySCuwl3DU4gSJMTM3eCk9uS11jKYXej/LRqlEA583TQMXA9vKEr3D BTA3YaATqU69cr3LkY+oFh6iSGwDWBjC71XRIW/Ztu8OJNAxMMCM7+FN1b1c+oCaGxa5 gEJe1ato3Xqz3KS2qFPfBduyST8EDQ3rgj6HoKhYmDmx2RkW79XnciLgSobUzsgaflVt r1+A== MIME-Version: 1.0 X-Received: by 10.194.118.166 with SMTP id kn6mr5576339wjb.18.1360270391272; Thu, 07 Feb 2013 12:53:11 -0800 (PST) Received: by 10.194.62.98 with HTTP; Thu, 7 Feb 2013 12:53:11 -0800 (PST) In-Reply-To: <008801ce0574$7373d7c0$5a5b8740$@packetizer.com> References: <008801ce0574$7373d7c0$5a5b8740$@packetizer.com> Date: Thu, 7 Feb 2013 12:53:11 -0800 Message-ID: From: Brad Fitzpatrick To: "webfinger@googlegroups.com" Content-Type: multipart/alternative; boundary=089e01228a2878660c04d528a1f8 X-Gm-Message-State: ALoCoQkl+etTfVAAxWEvSN4SJx+nAEGynXfoEpVVO75ASNqsjAV6ZWT/ITMABO8qx/MKFFYWte4jQzXiP5xkQHkJpzGV0XcfqeTRNVvm3kyd2LQ0Laairymkn3+1HJh2blA1EzA6pBpx8NPhpSq6d7oCaVdwHycXm0J80vKjreiMBue0Z5BaqHHxWc+XVj9/uaw25oyPWq7V Cc: "webfinger@ietf.org" Subject: Re: [webfinger] Renaming the "resource" parameter 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, 07 Feb 2013 20:53:24 -0000 --089e01228a2878660c04d528a1f8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I like "subject". I dislike "principal". I also don't really care. On Thu, Feb 7, 2013 at 12:48 PM, Paul E. Jones wrote= : > Folks,**** > > ** ** > > In the most recent round of edits (I hope to publish tomorrow) I made a > pass through the text to try to use the word =E2=80=9Cresource=E2=80=9D o= r =E2=80=9CWebFinger > resource=E2=80=9D rather than =E2=80=9CWebFinger server=E2=80=9D where it= made sense. (=E2=80=9CServer=E2=80=9D is > still used, but hopefully only when speaking of the web server itself.)**= * > * > > ** ** > > But, as I did that, I noticed that in at least one place the word > =E2=80=9Cresource=E2=80=9D (referring to the parameter that gets passed i= n) seemed to make > the text confusing. I put quotes around =E2=80=9Cresource=E2=80=9D when = I=E2=80=99m referring to > the parameter.**** > > ** ** > > The question is this: should we rename the =E2=80=9Cresource=E2=80=9D par= ameter to > something else?**** > > ** ** > > SWD used =E2=80=9Cprincipal=E2=80=9D and the JRD uses the term =E2=80=9Cs= ubject=E2=80=9D. I think either > of those would work as alternatives.**** > > ** ** > > Or, shall we continue with =E2=80=9Cresource=E2=80=9D? I think it=E2=80= =99s worded so that it=E2=80=99s > not confusing now, but I=E2=80=99m probably a poor judge of that since I = know is > meant.**** > > ** ** > > Paul**** > > ** ** > > -- > > --- > You received this message because you are subscribed to the Google Groups > "WebFinger" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to webfinger+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > --089e01228a2878660c04d528a1f8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I like "subject".

I dislike &= quot;principal".

I also don't really care= .



On Thu, Feb 7, 2013 at 12:48 PM, Paul E. Jones <paulej@packetizer.com<= /a>> wrote:

Folks,

=C2=A0

=

In the most recent round of edits (I hope to publish= tomorrow) I made a pass through the text to try to use the word =E2=80=9Cr= esource=E2=80=9D or =E2=80=9CWebFinger resource=E2=80=9D rather than =E2=80= =9CWebFinger server=E2=80=9D where it made sense.=C2=A0 (=E2=80=9CServer=E2= =80=9D is still used, but hopefully only when speaking of the web server it= self.)

=C2=A0

But, = as I did that, I noticed that in at least one place the word =E2=80=9Cresou= rce=E2=80=9D (referring to the parameter that gets passed in) seemed to mak= e the text confusing. =C2=A0I put quotes around =E2=80=9Cresource=E2=80=9D = when I=E2=80=99m referring to the parameter.

=C2=A0

The q= uestion is this: should we rename the =E2=80=9Cresource=E2=80=9D parameter = to something else?

=C2=A0=

SWD used =E2=80=9Cprincipal=E2=80=9D and the JRD uses the term =E2=80=9Csub= ject=E2=80=9D.=C2=A0 I think either of those would work as alternatives.=

=C2=A0

Or, shall we continue with =E2=80=9Cresource=E2=80=9D?=C2=A0 I th= ink it=E2=80=99s worded so that it=E2=80=99s not confusing now, but I=E2=80= =99m probably a poor judge of that since I know is meant.

=C2=A0

Paul

=C2=A0

--
=C2=A0
---
You received this message because you are subscribed to the Google Groups &= quot;WebFinger" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to webfinger+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
=C2=A0
=C2=A0

--089e01228a2878660c04d528a1f8-- From gsalguei@cisco.com Thu Feb 7 12:59: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 8300421F86FB for ; Thu, 7 Feb 2013 12:59:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.513 X-Spam-Level: X-Spam-Status: No, score=-10.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ykqgMAiE1aYj for ; Thu, 7 Feb 2013 12:59:43 -0800 (PST) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id D3A7521F86F5 for ; Thu, 7 Feb 2013 12:59:42 -0800 (PST) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r17Kxg9W028153 for ; Thu, 7 Feb 2013 15:59:42 -0500 (EST) Received: from dhcp-64-102-154-246.cisco.com (dhcp-64-102-154-246.cisco.com [64.102.154.246]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r17KxgLv010360; Thu, 7 Feb 2013 15:59:42 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Gonzalo Salgueiro In-Reply-To: <008801ce0574$7373d7c0$5a5b8740$@packetizer.com> Date: Thu, 7 Feb 2013 15:59:42 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <008801ce0574$7373d7c0$5a5b8740$@packetizer.com> To: "Paul E. Jones" X-Mailer: Apple Mail (2.1499) Cc: webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] Renaming the "resource" parameter 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, 07 Feb 2013 20:59:43 -0000 At this point "resource" is cemented in my mind as the name for the = parameter. My preference is to stick with it. Using quotes seems a = sufficient clarification of its usage as a parameter. Gonzalo On Feb 7, 2013, at 3:48 PM, Paul E. Jones wrote: > Folks, > =20 > In the most recent round of edits (I hope to publish tomorrow) I made = a pass through the text to try to use the word =93resource=94 or = =93WebFinger resource=94 rather than =93WebFinger server=94 where it = made sense. (=93Server=94 is still used, but hopefully only when = speaking of the web server itself.) > =20 > But, as I did that, I noticed that in at least one place the word = =93resource=94 (referring to the parameter that gets passed in) seemed = to make the text confusing. I put quotes around =93resource=94 when I=92m= referring to the parameter. > =20 > The question is this: should we rename the =93resource=94 parameter to = something else? > =20 > SWD used =93principal=94 and the JRD uses the term =93subject=94. I = think either of those would work as alternatives. > =20 > Or, shall we continue with =93resource=94? I think it=92s worded so = that it=92s not confusing now, but I=92m probably a poor judge of that = since I know is meant. > =20 > Paul > =20 > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger From paulej@packetizer.com Thu Feb 7 13:54: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 553B721F841E for ; Thu, 7 Feb 2013 13:54:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mglpt9Llvcs6 for ; Thu, 7 Feb 2013 13:54:48 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 81D2021F841C for ; Thu, 7 Feb 2013 13:54:48 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r17Lshls016940 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Feb 2013 16:54:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1360274084; bh=RvYT+wDny1VWCJhmgh22yNUgHQqasIC/At2S+tJgPi8=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=me0n3L+yGZdThOtVS0dH28jgVcrHW9eTlj2vkbHIhEm+E25eTKlCOSSJdviFZorRY HHvPMNIjmOlrWhH8ho4X/MIUxddvGjtEP9OZQ1wQmwaJie2KZ/102MyZ2A8D1hyxwQ CpM3GCBwpNAQWj9fjcNFw0S97qy1IA/uNjidFhYE= From: "Paul E. Jones" To: "'Barry Leiba'" References: <072501ce04f7$feee5af0$fccb10d0$@packetizer.com> In-Reply-To: Date: Thu, 7 Feb 2013 16:54:53 -0500 Message-ID: <00c301ce057d$c2e9b4b0$48bd1e10$@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: AQHQOHoCMnsY+wN4jZOrj0hn5M3hqAKvxZFgmFUMTkA= Content-Language: en-us Cc: webfinger@ietf.org Subject: Re: [webfinger] Media type for 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, 07 Feb 2013 21:54:49 -0000 OK.. I started that process. See my separated email. Paul > -----Original Message----- > From: barryleiba.mailing.lists@gmail.com > [mailto:barryleiba.mailing.lists@gmail.com] On Behalf Of Barry Leiba > Sent: Thursday, February 07, 2013 11:29 AM > To: Paul E. Jones > Cc: webfinger@ietf.org > Subject: Re: [webfinger] Media type for WebFinger > > As I said in the other thread: the purpose of a media type is to tag > your payload for situations where you don't know <> what it is. > No, it's not sufficient to say whether it's plain text, XML, or JSON > (for that matter, XML and JSON are plain text, aren't they?). > You have to know the context. It may be that in your use case, or even > in all the current use cases, you do know the context. But you can't > guarantee that will always be true, and defined media types let us plan > ahea. > > I can also assure you that you'll get pushback from the IESG on this > point (and not only from me). This isn't just empty process: there's > value in having a specific media type to tag data that's used for a > specific purpose. > > Now, it's not a difficult thing to define a media type, and it's > especially easy if you're already writing an RFC anyway. And it's also > easy to use the media type -- why's it harder to tag something as, say, > application/webfinger+json than as application/json? > > So, to two of your points, specifically: > > > And is WF going to be the first of a bunch of spec that create a bunch > > of JSON media types like there were for +xml? > > Probably yes. > > > I prefer application/json, unless there is a technical reason someone > > can bring to my attention to show why this is a bad idea. > > No, the question goes the other way 'round. Creating appropriate media > types is how we do this, so it needs to be done unless you (or someone > else) have a technical reason that *it* is a bad idea. > Really: if it's just that you don't like it or think it's unnecessary, I > get that and I sympathise, but that's not a valid reason (others and I > have already said why we do think it's necessary). If you *do* have a > reason that it's actively bad, state it and people will listen. > > Barry, Applications AD > > On Thu, Feb 7, 2013 at 12:57 AM, Paul E. Jones > wrote: > > Folks, > > > > Most of the comments received have been editorial. I've tried to > > capture all of them, though there is the possibility one slips > > through. None seem like showstoppers. > > > > However, one comment that I've not taken action on is defining a media > > type for WebFinger. There are split views on this. Some are arguing > > we need something and others say we don't. Some say it might be > > helpful if present, but not everyone agrees. > > > > Personally, I'm in the camp that we do not need anything more than > > application/json. A query to a WebFinger resource means one would get > > a WF response and the application type is really not so important. It > > is important to know that it's application/json vs. XML or plain text > > or other, but to introduce something like application/jrd+json or some > > such seems like overkill to me. I've not seen this done for the > > gazillion other web services that use JSON. > > > > So, is there truly a need to have an dedicated type? If so, what > > should be the name of this type? And is WF going to be the first of a > > bunch of spec that create a bunch of JSON media types like there were > for +xml? > > > > I prefer application/json, unless there is a technical reason someone > > can bring to my attention to show why this is a bad idea. > > > > Paul From paulej@packetizer.com Thu Feb 7 13:57:31 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 53CB321E8034 for ; Thu, 7 Feb 2013 13:57:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mU-COSfLXxmC for ; Thu, 7 Feb 2013 13:57:30 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 7910421F8CBF for ; Thu, 7 Feb 2013 13:57:30 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r17Ls2mi016897 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Feb 2013 16:54:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1360274043; bh=b7xbI2SSS/E0QE0qwCFMgtztUlPHJE3S3B//IoObpyY=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding; b=MiqEvDz/BYdxOB0df/AyzMSZSqF7S94chQOQMC0Qa8xK6uu1oUF/X15HdY+4Ovvat OozECzo/O1pvgh+zGoi8RALOQhZJ3O5vGkdOjn4cWHcdSqWRkE4fPArJVpHAoh8ToP IrMz7k7CiSGaZu68duUCGBGhChsywYXtOXNKFoBU= From: "Paul E. Jones" To: Date: Thu, 7 Feb 2013 16:54:11 -0500 Message-ID: <00c101ce057d$aa4d3300$fee79900$@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: Ac4FfHmd22VIzEXXTX+0vfeMXSyCnA== Content-Language: en-us Cc: webfinger@ietf.org, Barry Leiba Subject: [webfinger] Media type application/jrd+json 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, 07 Feb 2013 21:57:31 -0000 Folks, Barry Leiba indicated that we should register the a media type for the resource representation defined in http://tools.ietf.org/html/draft-ietf-appsawg-webfinger called the JSON Resource Descriptor (JRD). I am sending this for your review and comments back as we are working to finalize the draft. I have not completed a template for application types before and I see there are a few new things in the template, so please do let me know if there is anything that needs clarification or should be changed. Thanks, Paul ================================================ Type name: application Subtype name: jrd+json Required parameters: N/A Optional parameters: N/A "charset" - Indicates the character set used to encode the JSON Resource Descriptor. If absent, UTF-8 is assumed. Encoding considerations: 8bit Security considerations: The JSON Resource Descriptor (JRD) is a JavaScript Object Notation (JSON) object. It is a text format that must be parsed by entities that wish to utilize the format. Depending on the language and mechanism used to parse a JSON object, it is possible for an attacker to inject behavior into a running program. Therefore, care must be taken to properly parse a received JRD to ensure that only a valid JSON object is present and that no JavaScript code is injected or executed unexpectedly. Interoperability considerations: This media type is a JavaScript Object Notation (JSON) object and can be consumed by any software application that can consume JSON objects. Published specification: RFC QQQ Applications that use this media type: WebFinger Fragment identifier considerations: N/A Additional information: Deprecated alias names for this type: N/A Magic number(s): N/A File extension(s): jrd+json Macintosh file type code(s): N/A Person & email address to contact for further information: Paul E. Jones Intended usage: COMMON Restrictions on usage: N/A Author: Paul E. Jones Change controller: Paul E. Jones Provisional registration? (standards tree only): N/A From barryleiba.mailing.lists@gmail.com Thu Feb 7 14:42: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 03DCD1F0D04 for ; Thu, 7 Feb 2013 14:42:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.852 X-Spam-Level: X-Spam-Status: No, score=-102.852 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z+FMw2uDKN-H for ; Thu, 7 Feb 2013 14:42:57 -0800 (PST) Received: from mail-vb0-f46.google.com (mail-vb0-f46.google.com [209.85.212.46]) by ietfa.amsl.com (Postfix) with ESMTP id B5C391F0CFF for ; Thu, 7 Feb 2013 14:42:57 -0800 (PST) Received: by mail-vb0-f46.google.com with SMTP id b13so1923196vby.19 for ; Thu, 07 Feb 2013 14:42:57 -0800 (PST) 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=rgyLt0JGlhUuCYP59DcdBNE41Mi7gVv5LHpZ1wKQo94=; b=LnmxDQiolQ2YXPQurBkRq5UaSOhVWKPAjapBbMSqM3PMYauQM2eClb95lA/6NKppkQ Q5bIar1Mq7Iz1aX20JJEz9YQk3dRku7D1NN0LGTMq5VfvKxf/bPm8uqRg3keg+ao04qO /CAH6tYrj2ScuN4wYkGjXLtPdn7lKEu1w3kuHLZfEKhhxCfQSomUU9gaH4uTKR2/d2k5 IOVdZIjdA88yggI3n/tW9vb2iKncKPkluPHJbTkdF9id1QbXiGb5KR5/DRYgXq+A7v8U SUVqBUxrWfagcfWlzq1TpT0odshTaaK26IYhyunTFgvLg6pl3hGAw9MjBpuqPUdJHkpc vOEA== MIME-Version: 1.0 X-Received: by 10.58.117.229 with SMTP id kh5mr4064977veb.27.1360276977011; Thu, 07 Feb 2013 14:42:57 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.59.3.41 with HTTP; Thu, 7 Feb 2013 14:42:56 -0800 (PST) In-Reply-To: <044b01ce042e$965e1d00$c31a5700$@packetizer.com> References: <5106BFDC.2030706@ericsson.com> <5106C090.8080403@ericsson.com> <6.2.5.6.2.20130131151432.0aaf2b68@resistor.net> <044b01ce042e$965e1d00$c31a5700$@packetizer.com> Date: Thu, 7 Feb 2013 17:42:56 -0500 X-Google-Sender-Auth: fq8Pr5d5vI2TIrqDAlNe5D0WRRQ Message-ID: From: Barry Leiba To: "Paul E. Jones" Content-Type: text/plain; charset=ISO-8859-1 Cc: SM , "webfinger@ietf.org" Subject: Re: [webfinger] [apps-discuss] Working Group Last Call for draft-ietf-appsawg-webfinger-09 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, 07 Feb 2013 22:42:59 -0000 > You just want to replace all references to webfinger.net with something like > example.com or webfinger.example? > > The reason these are here is that these are in use today. I don't mind > changing them, though. What do others think? I see this is resolved, but just for the record: The reason for RFC 2606 was exactly that we *were* using names that are actually in use (or that later came into use), and the owners of those domains were getting annoyance traffic because people were copying the domain names directly from the documents. Never underestimate..... Using the reserved names also avoids trademark issues, as well as questions of favoritism or endorsement (should we put things such as "facebook.com" in an RFC). Sigh. Barry From ve7jtb@ve7jtb.com Thu Feb 7 15:21: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 CAE4221F85E2 for ; Thu, 7 Feb 2013 15:21:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVLJBszC43Eo for ; Thu, 7 Feb 2013 15:21:58 -0800 (PST) Received: from mail-da0-f43.google.com (mail-da0-f43.google.com [209.85.210.43]) by ietfa.amsl.com (Postfix) with ESMTP id D4EDD21F8620 for ; Thu, 7 Feb 2013 15:21:58 -0800 (PST) Received: by mail-da0-f43.google.com with SMTP id u36so1490109dak.30 for ; Thu, 07 Feb 2013 15:21:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=2RMhRQ4/oN1u32/Adaa8l8oNxul4sJnbyG34z0NHDA4=; b=I86PSyLBJI3C14hNEpUUYbOSj6Zouq2Il0E1DrZg9bIbbG5Cr1RS6ZdfT5SF2a1XpO JzbcQ8iLcuAA2v6G8yk2sQ+90O9zSSpA6l6Mj9o7+QshXYvj9dkunbc8Kozm0CBpWcEH 5a7MzdzgKrw4SHsEZrimxMiVWY7+mkjtMqDcePSDA0VTxjBsIPHiKAxAPSHB/iTa58Pk TE+El4atCrRnNNA4YuFx2OSyqgS+qqd6fl1h9L8srw+ZuAUgQxc1qAYiQxVLnHnCv8rr CDCjyAp+pbDlVMP+q0WZ5MjiZcqIVYg+YbRmnDjJtWZZ2/KZhclDhcFEvyzYpzGQWZxN oX8Q== X-Received: by 10.66.74.234 with SMTP id x10mr10741738pav.10.1360279318110; Thu, 07 Feb 2013 15:21:58 -0800 (PST) Received: from [192.168.43.179] (mobile-166-137-218-148.mycingular.net. [166.137.218.148]) by mx.google.com with ESMTPS id z10sm49387174pay.7.2013.02.07.15.21.54 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Feb 2013 15:21:56 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_39098C8B-F580-40FD-99C9-82E1AF4BF8DB"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: Date: Thu, 7 Feb 2013 16:21:53 -0700 Message-Id: References: <006601ce0571$c2b9c180$482d4480$@packetizer.com> To: webfinger@googlegroups.com X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQnSKZhrEr4dzhRJinYRtXxyb9VmzIuQ0hGYksaDQq/LXUGRaR3FpliVmmN7VKcHLMxaZxU4 Cc: Brad Fitzpatrick , "webfinger@ietf.org" Subject: Re: [webfinger] The "expires" member of the JRD 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, 07 Feb 2013 23:21:59 -0000 --Apple-Mail=_39098C8B-F580-40FD-99C9-82E1AF4BF8DB Content-Type: multipart/alternative; boundary="Apple-Mail=_04ECE5DC-715F-4FA5-B1E5-051097E49F69" --Apple-Mail=_04ECE5DC-715F-4FA5-B1E5-051097E49F69 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Yes it is a XRI legacy. Get rid of it.=20 John B. On 2013-02-07, at 1:52 PM, Tim Bray wrote: > +1 >=20 >=20 > On Thu, Feb 7, 2013 at 12:35 PM, Brad Fitzpatrick = wrote: > I'd be happy seeing it removed. >=20 > HTTP seems sufficient. >=20 >=20 >=20 > On Thu, Feb 7, 2013 at 12:28 PM, Paul E. Jones = wrote: > Folks, >=20 > =20 >=20 > Questions have been raised about the =93expires=94 member of the JRD = two or three times now, with concerns related to the fact that HTTP has = multiple ways of also indicating how long a resource representation = should be cached. >=20 > =20 >=20 > This element is exists for historical reason, but it=92s not clear to = me if anyone is using it or cares to use it. >=20 > =20 >=20 > Shall we keep it or just remove it from the spec entirely? >=20 > =20 >=20 > Paul >=20 > =20 >=20 >=20 > --=20 > =20 > ---=20 > You received this message because you are subscribed to the Google = Groups "WebFinger" group. > To unsubscribe from this group and stop receiving emails from it, send = an email to webfinger+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > =20 > =20 >=20 >=20 > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger >=20 >=20 >=20 > --=20 > =20 > ---=20 > You received this message because you are subscribed to the Google = Groups "WebFinger" group. > To unsubscribe from this group and stop receiving emails from it, send = an email to webfinger+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > =20 > =20 --Apple-Mail=_04ECE5DC-715F-4FA5-B1E5-051097E49F69 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Yes = it is a XRI legacy.  Get rid of it. 

John = B.


+1


On Thu, Feb 7, = 2013 at 12:35 PM, Brad Fitzpatrick <bradfitz@google.com> wrote:
I'd = be happy seeing it removed.

HTTP seems = sufficient.



On Thu, Feb 7, 2013 at 12:28 PM, Paul E. Jones <paulej@packetizer.com> wrote:

Folks,

 

Questions have been raised about the =93expires=94 = member of the JRD two or three times now, with concerns related to the = fact that HTTP has multiple ways of also indicating how long a resource = representation should be cached.

 

This = element is exists for historical reason, but it=92s not clear to me if = anyone is using it or cares to use it.

 

Shall = we keep it or just remove it from the spec entirely?

 

Paul

 


--
 
---
You received this message because you are subscribed to the Google = Groups "WebFinger" group.
To unsubscribe from this group and stop receiving emails from it, send = an email to webfinger+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 


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



--
 
---
You received this message because you are subscribed to the Google = Groups "WebFinger" group.
To unsubscribe from this group and stop receiving emails from it, send = an email to webfinger+unsubscri= be@googlegroups.com.
For more options, visit https://groups.google.co= m/groups/opt_out.
 
 

= --Apple-Mail=_04ECE5DC-715F-4FA5-B1E5-051097E49F69-- --Apple-Mail=_39098C8B-F580-40FD-99C9-82E1AF4BF8DB Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMjA3MjMyMTUzWjAjBgkqhkiG9w0BCQQxFgQUWjVse5ZZ T4fQsvSO7D6rUTIgYH0wgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEADlWFzWSYqXfHdVXt6lkBaKTCAIygEJDweVJq0xTw /i8numEFmZRfkuAj/KC4KkpZYWNuG1hk1vUYax9ICtZE4lumm8/KB6FSVK9HrTmZCUI11nYN/hGN mK76bBYqXeQuCcerMbdn3hU0hzLKNfvJ4BUyI19NKpnXFVx+oDjldYcA5s75HvE4zmoNxMFfJFBk j6tDyYZbBRDbavD4tWXUf0JZqH2Vu10JNG9egdumjMuW7DfjV51c57P6WKJtzeWsomlArUKjnhLl pYY5L7n6Yg4+WGbigKdVWQADDQnAXkV+FZHgGcDllzYoYjxGTaOkhVS+hPcpc+jUq4iFJ+9ENwAA AAAAAA== --Apple-Mail=_39098C8B-F580-40FD-99C9-82E1AF4BF8DB-- From mnot@mnot.net Thu Feb 7 15:56:13 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 43CE821F89D5 for ; Thu, 7 Feb 2013 15:56:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.399 X-Spam-Level: X-Spam-Status: No, score=-105.399 tagged_above=-999 required=5 tests=[AWL=-2.800, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OAvnE5+63rN6 for ; Thu, 7 Feb 2013 15:56:12 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8A221F858E for ; Thu, 7 Feb 2013 15:56:12 -0800 (PST) Received: from [192.168.1.80] (unknown [118.209.138.158]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9412D22E257; Thu, 7 Feb 2013 18:56:05 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Mark Nottingham In-Reply-To: <009501ce0574$7da4ca60$78ee5f20$@packetizer.com> Date: Fri, 8 Feb 2013 10:56:02 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <046e01ce0437$43df8ec0$cb9eac40$@packetizer.com> <076a01ce050d$b0a8f6a0$11fae3e0$@packetizer.com> <18645BD5-3F95-4EAC-8693-219539257FA5@mnot.net> <009501ce0574$7da4ca60$78ee5f20$@packetizer.com> To: Paul E. Jones X-Mailer: Apple Mail (2.1499) Cc: webfinger@ietf.org Subject: Re: [webfinger] [apps-discuss] WGLC feedback on webfinger-09 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, 07 Feb 2013 23:56:13 -0000 On 08/02/2013, at 7:48 AM, Paul E. Jones wrote: >=20 > I'd prefer to leave the intro alone, since we do cover every point you = made, > I think. To address your initial point by modifying the abstract to = read: >=20 > 'This specification defines the WebFinger protocol, which can be used = to > discover information about people or other entities on the Internet = using > standard HTTP methods. WebFinger discovers information for a URI that = might > not be usable as a locator otherwise, such as account or email URIs.' Good. ... >>> the server when issuing a request. These parameters, "resource" and >>> "rel", and the parameter values are included in the "query" = component >>> of the URI (see Section 3.4 of RFC 3986). To construct the "query" >>> component, the >>=20 >> no scare quotes needed >=20 > I assume that's just around "query". I do prefer to keep them around > "resource" and "rel" since those are being first formally introduced = in this > section. Yes. ... >>>> Also, consider replacing "WebFinger server" with "WebFinger = Resource". >>>=20 >>> That might be doable, but I need to look through the whole document. >>> We use "server" in a lot of places. We also use the word client a >>> lot, as the terminology used has been client/server centric. So, I >>> need to ensure the wording sounds right. I'm sure I'll mess that up >>> ;-) >>>=20 >>> How do others feel about this one? >>>=20 >=20 > I changed the text to refer to "webfinger resource" or "resource". = Server > is used sparingly and I tried to use it only when referring to = functions > provided by the web server. WFM. ... > I do not understand how an HTTP client (browser or caching server) can > accommodate for clock differences. If the client and server think the = time > is 15 minutes apart, then the timestamps are wrong for one or the = other or > both. Of course, using the "max-age" parameter helps, as time is not = given > in absolute terms. >=20 > Clock drift and merely having the wrong time are two different issues, = too. > We deal with clock drift in NTP and real-time communications, but = caching > servers do? I'm confused. = https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p6-cac= he.html#age.calculations ... > Honestly, I never gathered that from 5988 before. RFC 5988 even says: > 'The "type" parameter, when present, is a hint indicating what the = media > type of the result of dereferencing the link should be.' >=20 > It sounds very singular to me. If we were to allow multiple types, = they > would either have to be space-separated or we would have to change = "type" to > an array. I suspect there would be resistence to that, especially = since > "type" is merely a hint w.r.t. the media type that will be returned. *mumble* The model in 5988 isn't very clear. In truth, the mapping of = parameters (that word again) from different serialisations is ad hoc, at = best. ... > I've made an effort to do that. Now, though, I don't like the = parameter > name "resource". Where it appears in prose, I put quotes around it so > people are not confused with the WebFinger resource. Sounds good. Cheers and thanks, -- Mark Nottingham http://www.mnot.net/ From Michael.Jones@microsoft.com Thu Feb 7 15:56:20 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 43C6F21F89D5 for ; Thu, 7 Feb 2013 15:56:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4yapXcrBFDC for ; Thu, 7 Feb 2013 15:56:18 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.23]) by ietfa.amsl.com (Postfix) with ESMTP id 6119621F858E for ; Thu, 7 Feb 2013 15:56:18 -0800 (PST) Received: from BY2FFO11FD003.protection.gbl (10.1.15.202) by BY2FFO11HUB023.protection.gbl (10.1.14.110) with Microsoft SMTP Server (TLS) id 15.0.609.9; Thu, 7 Feb 2013 23:56:07 +0000 Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD003.mail.protection.outlook.com (10.1.14.125) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Thu, 7 Feb 2013 23:56:07 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.132]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0318.003; Thu, 7 Feb 2013 23:55:28 +0000 From: Mike Jones To: John Bradley , "webfinger@googlegroups.com" Thread-Topic: [webfinger] The "expires" member of the JRD Thread-Index: Ac4FcYIMOfmxZ3J+RmCz066Z8WbK1QAAR/IAAACZCYAABTjvgAABKqbg Date: Thu, 7 Feb 2013 23:55:28 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436741C056@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <006601ce0571$c2b9c180$482d4480$@packetizer.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436741C056TK5EX14MBXC284r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(377424002)(24454001)(189002)(199002)(77982001)(74502001)(79102001)(54356001)(5343655001)(53806001)(4396001)(20776003)(56816002)(31966008)(14971765001)(44976002)(66066001)(33656001)(15202345001)(80022001)(49866001)(74662001)(47736001)(63696002)(5343635001)(59766001)(47446002)(76482001)(55846006)(51856001)(56776001)(50986001)(16406001)(65816001)(54316002)(16236675001)(512954001)(46102001)(47976001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB023; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0750463DC9 Cc: Brad Fitzpatrick , "webfinger@ietf.org" Subject: Re: [webfinger] The "expires" member of the JRD 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, 07 Feb 2013 23:56:20 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436741C056TK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Beh= alf Of John Bradley Sent: Thursday, February 07, 2013 3:22 PM To: webfinger@googlegroups.com Cc: Brad Fitzpatrick; webfinger@ietf.org Subject: Re: [webfinger] The "expires" member of the JRD Yes it is a XRI legacy. Get rid of it. John B. On 2013-02-07, at 1:52 PM, Tim Bray > wrote: +1 On Thu, Feb 7, 2013 at 12:35 PM, Brad Fitzpatrick > wrote: I'd be happy seeing it removed. HTTP seems sufficient. On Thu, Feb 7, 2013 at 12:28 PM, Paul E. Jones > wrote: Folks, Questions have been raised about the "expires" member of the JRD two or thr= ee times now, with concerns related to the fact that HTTP has multiple ways= of also indicating how long a resource representation should be cached. This element is exists for historical reason, but it's not clear to me if a= nyone is using it or cares to use it. Shall we keep it or just remove it from the spec entirely? Paul -- --- You received this message because you are subscribed to the Google Groups "= WebFinger" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to webfinger+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. _______________________________________________ webfinger mailing list webfinger@ietf.org https://www.ietf.org/mailman/listinfo/webfinger -- --- You received this message because you are subscribed to the Google Groups "= WebFinger" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to webfinger+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. --_000_4E1F6AAD24975D4BA5B16804296739436741C056TK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1<= /p>

 <= /p>

From: webfinge= r-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of John Bradley
Sent: Thursday, February 07, 2013 3:22 PM
To: webfinger@googlegroups.com
Cc: Brad Fitzpatrick; webfinger@ietf.org
Subject: Re: [webfinger] The "expires" member of the JRD

 

Yes it is a XRI legacy.  Get rid of it. 

 

John B.

 

On 2013-02-07, at 1:52 PM, Tim Bray <tbray@textuality.com> wrote:<= /p>



+1

 

On Thu, Feb 7, 2013 at 12:35 PM, Brad Fitzpatrick &l= t;bradfitz@google.= com> wrote:

I'd be happy seeing it removed.

 

HTTP seems sufficient.

 

 

On Thu, Feb 7, 2013 at 12:28 PM, Paul E. Jones <<= a href=3D"mailto:paulej@packetizer.com" target=3D"_blank">paulej@packetizer= .com> wrote:

Folks,

 

Questions have been raised about the “expires” member = of the JRD two or three times now, with concerns related to the fact that H= TTP has multiple ways of also indicating how long a resource representation should be cached.

 

This element is exists for historical reason, but it’s not c= lear to me if anyone is using it or cares to use it.

 

Shall we keep it or just remove it from the spec entirely?

 

Paul

 

 

--
 
---
You received this message because you are subscribed= to the Google Groups "WebFinger" group.
To unsubscribe from this group and stop receiving em= ails from it, send an email to webfinger+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

 


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

 

 

--
 
---
You received this message because you are subscribed to the Google Groups &= quot;WebFinger" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to webfinger+= ;unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

 

--_000_4E1F6AAD24975D4BA5B16804296739436741C056TK5EX14MBXC284r_-- From dick.hardt@gmail.com Thu Feb 7 16:17: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 1705E21F8955 for ; Thu, 7 Feb 2013 16:17:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.764 X-Spam-Level: X-Spam-Status: No, score=-1.764 tagged_above=-999 required=5 tests=[AWL=-1.836, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRrIVa9g7vxP for ; Thu, 7 Feb 2013 16:17:37 -0800 (PST) Received: from mail-ia0-x22f.google.com (mail-ia0-x22f.google.com [IPv6:2607:f8b0:4001:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 8133C21F841F for ; Thu, 7 Feb 2013 16:17:37 -0800 (PST) Received: by mail-ia0-f175.google.com with SMTP id r4so3524097iaj.6 for ; Thu, 07 Feb 2013 16:17:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=yXQ7+h0eb5t6qLXeerIht2AqMde/U3oyT3L8I+/hhr8=; b=NBxgZptV6Z+hTfK8+m48nA9t1fJv0EyjJox/TVf8vlEzkIxn3zQzhZmMkTHKnqLlfB pV4f6QGz+5dTQ7zK5/TGJ0gUc3HuROWL3uBKNRkToh6DfrJpUk6hs213p6wKd50lxIGo 9OKsVegg27h5ex2uE4pKJYJQBDFR+zyV8kQ22Nw6fDWi7GktJZ3WpMbVqTiiKeg4Tmf4 qimSlWcEelOl/AzX1n2KihQvDlfMZJHXWWabxAGfXRKBSFfLdcH/kjh+qP5RYhNrq+hY 5k7y5P/8UJZK4b0uPT7mF0RqPiBmK8M/+UfErULcBqTjCkVBtKcAuDIZQ7sTKlkoDZSv Vq8w== X-Received: by 10.50.88.136 with SMTP id bg8mr6887585igb.96.1360282657096; Thu, 07 Feb 2013 16:17:37 -0800 (PST) Received: from [172.16.33.108] ([206.108.25.22]) by mx.google.com with ESMTPS id fa6sm12102170igb.2.2013.02.07.16.17.34 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Feb 2013 16:17:36 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_78EFD7CC-F191-4F4E-8DFF-0E3888D5834F" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dick Hardt In-Reply-To: Date: Thu, 7 Feb 2013 16:17:34 -0800 Message-Id: <368FB88B-7179-4428-A08A-C7201B8B4EF2@gmail.com> References: <072501ce04f7$feee5af0$fccb10d0$@packetizer.com> <632DD91F-6715-473D-81EE-8C58686B13BA@gmail.com> To: Tim Bray X-Mailer: Apple Mail (2.1499) Cc: "webfinger@ietf.org" , "Paul E. Jones" , Barry Leiba , Dick Hardt Subject: Re: [webfinger] Media type for 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, 08 Feb 2013 00:17:38 -0000 --Apple-Mail=_78EFD7CC-F191-4F4E-8DFF-0E3888D5834F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Feb 7, 2013, at 9:17 AM, Tim Bray wrote: > On Thu, Feb 7, 2013 at 9:02 AM, Dick Hardt = wrote: > Barry >=20 > To help the less knowledgeable such as myself, would you be kind = enough to point out some examples of similar protocols that are widely = deployed that defined a new media type? >=20 > I=92ve got a better idea; why don=92t we just stop arguing over this = stupid bikeshed issue and do what our AD just asked us to do. I apologize for coming in late on this conversation and if it has been = discussed significantly already. Speaking as a developer, having a media type other than application/json = looks to cause me a bunch of hassle. When writing a server, I would have = to explicitly set the header rather than just writing a JSON object and = letting my server to the right thing, and when writing a client, my = libraries will give me a parsed object automatically if it is = application/json. I already know if I am serving or requesting Web = Finger data, so I am confused about the value I would get as a developer = having a media type other than application/json. -- Dick= --Apple-Mail=_78EFD7CC-F191-4F4E-8DFF-0E3888D5834F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 tbray@textuality.com> = wrote:
On Thu, Feb 7, 2013 at 9:02 AM, Dick = Hardt <dick.hardt@gmail.com> wrote:
Barry

To help the less knowledgeable such as myself, would you be kind enough = to point out some examples of similar protocols that are widely deployed = that defined a new media type?

I=92ve = got a better idea; why don=92t we just stop arguing over this stupid = bikeshed issue and do what our AD just asked us to = do.

I apologize = for coming in late on this conversation and if it has been discussed = significantly already.

Speaking as a developer, = having a media type other than application/json looks to cause me a = bunch of hassle. When writing a server, I would have to explicitly set = the header rather than just writing a JSON object and letting my server = to the right thing, and when writing a client, my libraries will give me = a parsed object automatically if it is application/json. I already know = if I am serving or requesting Web Finger data, so I am confused about = the value I would get as a developer having a media type other than = application/json.

-- Dick
= --Apple-Mail=_78EFD7CC-F191-4F4E-8DFF-0E3888D5834F-- From melvincarvalho@gmail.com Thu Feb 7 18:37: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 56A7F21F8467 for ; Thu, 7 Feb 2013 18:37:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMsR2TazPoi6 for ; Thu, 7 Feb 2013 18:37:44 -0800 (PST) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 48C6921F8481 for ; Thu, 7 Feb 2013 18:37:44 -0800 (PST) Received: by mail-ie0-f170.google.com with SMTP id c11so4512299ieb.15 for ; Thu, 07 Feb 2013 18:37:44 -0800 (PST) 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=Rb9yr67dTro6SQRTqD4p92eawCAQT1wIdMzTV8LAsAE=; b=itkL1rL+LwmtLTXN8qRsXRRm2UVs00j6tBayyOYhTVr2kxyEkntp8HgHHJVwJprPqr /EZqlbnKc3pacTzxBh8Dd/WgIoN1xpwT6HvQGDBvOm9j36Kj2MbkH4kWGdxE3vkpzar5 5qMGjM/EhjsMkSkGvemOjwF7ujvGeIe5s0MPattoYVfzOajG8xT2eQQntHWO4jawDVz0 MIqSvHtzGceMX29FtnEOguja0H3SjMhn2RfvPOL2vYKMKfplBkvvwfYS+3G/JDT7nXLl mG6d9/L8z7MPry5KwT+kNFxnWJPj0rbFucFGFqCb7Ba9npnnI9BW82CaOaery3729pfQ jwdA== MIME-Version: 1.0 X-Received: by 10.50.45.168 with SMTP id o8mr18924250igm.41.1360291063917; Thu, 07 Feb 2013 18:37:43 -0800 (PST) Received: by 10.43.101.5 with HTTP; Thu, 7 Feb 2013 18:37:43 -0800 (PST) In-Reply-To: <368FB88B-7179-4428-A08A-C7201B8B4EF2@gmail.com> References: <072501ce04f7$feee5af0$fccb10d0$@packetizer.com> <632DD91F-6715-473D-81EE-8C58686B13BA@gmail.com> <368FB88B-7179-4428-A08A-C7201B8B4EF2@gmail.com> Date: Fri, 8 Feb 2013 03:37:43 +0100 Message-ID: From: Melvin Carvalho To: Dick Hardt Content-Type: multipart/alternative; boundary=14dae93403a9a7eadd04d52d71aa Cc: "webfinger@ietf.org" , Barry Leiba , Tim Bray , "Paul E. Jones" Subject: Re: [webfinger] Media type for 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, 08 Feb 2013 02:37:45 -0000 --14dae93403a9a7eadd04d52d71aa Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 8 February 2013 01:17, Dick Hardt wrote: > > On Feb 7, 2013, at 9:17 AM, Tim Bray wrote: > > On Thu, Feb 7, 2013 at 9:02 AM, Dick Hardt wrote: > >> Barry >> >> To help the less knowledgeable such as myself, would you be kind enough >> to point out some examples of similar protocols that are widely deployed >> that defined a new media type? >> > > I=92ve got a better idea; why don=92t we just stop arguing over this stup= id > bikeshed issue and do what our AD just asked us to do. > > > I apologize for coming in late on this conversation and if it has been > discussed significantly already. > > Speaking as a developer, having a media type other than application/json > looks to cause me a bunch of hassle. When writing a server, I would have = to > explicitly set the header rather than just writing a JSON object and > letting my server to the right thing, and when writing a client, my > libraries will give me a parsed object automatically if it is > application/json. I already know if I am serving or requesting Web Finger > data, so I am confused about the value I would get as a developer having = a > media type other than application/json. > Hi Dick, thanks for your comments, is this really big hassle, I would expect maximum one line of code in most programming languages. To my mind the question lies with interop ... there are many serializations on the internet, and giving a media type is way to tell a wider audience what then can expect > > -- Dick > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > > --14dae93403a9a7eadd04d52d71aa Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On 8 February 2013 01:17, Dick Hardt <dick.hardt@gmail.com> wrote:

On Feb = 7, 2013, at 9:17 AM, Tim Bray <tbray@textuality.com> wrote:

On Thu, Feb 7, 2013 at 9:02 AM, Dick Hardt <dick.hardt= @gmail.com> wrote:
Barry

To help the less knowledgeable such as myself, would you be kind enough to = point out some examples of similar protocols that are widely deployed that = defined a new media type?

I=92ve got a = better idea; why don=92t we just stop arguing over this stupid bikeshed iss= ue and do what our AD just asked us to do.

I apologize for c= oming in late on this conversation and if it has been discussed significant= ly already.

Speaking as a developer, having a medi= a type other than application/json looks to cause me a bunch of hassle. Whe= n writing a server, I would have to explicitly set the header rather than j= ust writing a JSON object and letting my server to the right thing, and whe= n writing a client, my libraries will give me a parsed object automatically= if it is application/json. I already know if I am serving or requesting We= b Finger data, so I am confused about the value I would get as a developer = having a media type other than application/json.

Hi Dick, thanks for your comments, is this real= ly big hassle, I would expect maximum one line of code in most programming = languages.=A0 To my mind the question lies with interop ... there are many = serializations on the internet, and giving a media type is way to tell a wi= der audience what then can expect
=A0

-- Dick=

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


--14dae93403a9a7eadd04d52d71aa-- From paulej@packetizer.com Thu Feb 7 19:30: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 6453A21E8053 for ; Thu, 7 Feb 2013 19:30:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtLHwrrHHfTb for ; Thu, 7 Feb 2013 19:30:40 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 42B3921E8034 for ; Thu, 7 Feb 2013 19:30:40 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r183UaqF001966 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Feb 2013 22:30:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1360294238; bh=3CWSZ8cfdvxKXq/NkD74VPASWv3J1IQXR1pfaodI+GU=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=lfO7cEWDg3IE1xtGlOuV3Tie55v6qacAwNJScHSDdANxnGonAAxIV8C7WfaIyt87M U83T48TydQclIEGvEFCLbWtKSM3lmfAtkb5ZAI5e6+AaitOMBs6I9S6wS69kqC2sfs /jJafLuoJe1nQzF0XtTbO715N14279brigPCdz0w= From: "Paul E. Jones" To: , "'John Bradley'" References: <006601ce0571$c2b9c180$482d4480$@packetizer.com> <4E1F6AAD24975D4BA5B16804296739436741C056@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436741C056@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Thu, 7 Feb 2013 22:30:46 -0500 Message-ID: <011b01ce05ac$afef9170$0fceb450$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_011C_01CE0582.C71AC1F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKXfMoCXAlmI/1utHC7TAWtthn92QL4OzEaAhqiMBABhxvZOgFxg9k9lpwD1lA= Content-Language: en-us Cc: 'Brad Fitzpatrick' , webfinger@ietf.org Subject: Re: [webfinger] The "expires" member of the JRD 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, 08 Feb 2013 03:30:42 -0000 This is a multipart message in MIME format. ------=_NextPart_000_011C_01CE0582.C71AC1F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Seems to be overwhelming support. It's gone. From: webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] On Behalf Of Mike Jones Sent: Thursday, February 07, 2013 6:55 PM To: John Bradley; webfinger@googlegroups.com Cc: Brad Fitzpatrick; webfinger@ietf.org Subject: RE: [webfinger] The "expires" member of the JRD +1 From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of John Bradley Sent: Thursday, February 07, 2013 3:22 PM To: webfinger@googlegroups.com Cc: Brad Fitzpatrick; webfinger@ietf.org Subject: Re: [webfinger] The "expires" member of the JRD Yes it is a XRI legacy. Get rid of it. John B. On 2013-02-07, at 1:52 PM, Tim Bray wrote: +1 On Thu, Feb 7, 2013 at 12:35 PM, Brad Fitzpatrick wrote: I'd be happy seeing it removed. HTTP seems sufficient. On Thu, Feb 7, 2013 at 12:28 PM, Paul E. Jones wrote: Folks, Questions have been raised about the "expires" member of the JRD two or three times now, with concerns related to the fact that HTTP has multiple ways of also indicating how long a resource representation should be cached. This element is exists for historical reason, but it's not clear to me if anyone is using it or cares to use it. Shall we keep it or just remove it from the spec entirely? Paul -- --- You received this message because you are subscribed to the Google Groups "WebFinger" group. To unsubscribe from this group and stop receiving emails from it, send an email to webfinger+unsubscribe@googlegroups.com . For more options, visit https://groups.google.com/groups/opt_out. _______________________________________________ webfinger mailing list webfinger@ietf.org https://www.ietf.org/mailman/listinfo/webfinger -- --- You received this message because you are subscribed to the Google Groups "WebFinger" group. To unsubscribe from this group and stop receiving emails from it, send an email to webfinger+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- --- You received this message because you are subscribed to the Google Groups "WebFinger" group. To unsubscribe from this group and stop receiving emails from it, send an email to webfinger+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. ------=_NextPart_000_011C_01CE0582.C71AC1F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Seems to be overwhelming support.  It’s = gone.

 

From:= = webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] On = Behalf Of Mike Jones
Sent: Thursday, February 07, 2013 = 6:55 PM
To: John Bradley; = webfinger@googlegroups.com
Cc: Brad Fitzpatrick; = webfinger@ietf.org
Subject: RE: [webfinger] The = "expires" member of the = JRD

 

+1

 

From:= = webfinger-bounces@ietf.org= [mailto:webfinger-bounces@ietf.= org] On Behalf Of John Bradley
Sent: Thursday, = February 07, 2013 3:22 PM
To: webfinger@googlegroups.com=
Cc: Brad Fitzpatrick; webfinger@ietf.org
Subject:<= /b> Re: [webfinger] The "expires" member of the = JRD

 

Yes it is a = XRI legacy.  Get rid of it. 

 

John B.

 

On = 2013-02-07, at 1:52 PM, Tim Bray <tbray@textuality.com> = wrote:

 

+1

 

On Thu, Feb 7, 2013 at 12:35 PM, Brad Fitzpatrick = <bradfitz@google.com> = wrote:

I'd be happy seeing it = removed.

 

HTTP seems sufficient.

 

 

On Thu, Feb 7, 2013 at 12:28 PM, Paul E. Jones <paulej@packetizer.com> = wrote:

Folks,<= /o:p>

 <= /o:p>

Questions = have been raised about the “expires” member of the JRD two = or three times now, with concerns related to the fact that HTTP has = multiple ways of also indicating how long a resource representation = should be cached.

 <= /o:p>

This = element is exists for historical reason, but it’s not clear to me = if anyone is using it or cares to use it.

 <= /o:p>

Shall we = keep it or just remove it from the spec entirely?

 

Paul

 

 

-- =
 
--- =
You received this message because you = are subscribed to the Google Groups "WebFinger" = group.
To unsubscribe from this group and = stop receiving emails from it, send an email to webfinger+unsubscribe@googlegroups.com.
<= span class=3Dhoenzb>For more options, visit https://groups.google.com/groups/opt_out. 
 

 


______________________________________= _________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger

 

 

-- =
 
---
You received this message because you are = subscribed to the Google Groups "WebFinger" group.
To = unsubscribe from this group and stop receiving emails from it, send an = email to webfinger+unsubscr= ibe@googlegroups.com.
For more options, visit https://groups.google.c= om/groups/opt_out.
 
 

 

-- =
 
---
You received this message because you are = subscribed to the Google Groups "WebFinger" group.
To = unsubscribe from this group and stop receiving emails from it, send an = email to webfinger+unsubscr= ibe@googlegroups.com.
For more options, visit https://groups.google.c= om/groups/opt_out.
 
 

------=_NextPart_000_011C_01CE0582.C71AC1F0-- From Michael.Jones@microsoft.com Thu Feb 7 19:30: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 71F2721E805D for ; Thu, 7 Feb 2013 19:30:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o+hM8S9UjL2U for ; Thu, 7 Feb 2013 19:30:44 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.23]) by ietfa.amsl.com (Postfix) with ESMTP id 921EA21E8054 for ; Thu, 7 Feb 2013 19:30:44 -0800 (PST) Received: from BY2FFO11FD012.protection.gbl (10.1.15.203) by BY2FFO11HUB023.protection.gbl (10.1.14.110) with Microsoft SMTP Server (TLS) id 15.0.609.9; Fri, 8 Feb 2013 03:30:41 +0000 Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD012.mail.protection.outlook.com (10.1.14.130) with Microsoft SMTP Server (TLS) id 15.0.609.9 via Frontend Transport; Fri, 8 Feb 2013 03:30:41 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.132]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0318.003; Fri, 8 Feb 2013 03:30:31 +0000 From: Mike Jones To: Gonzalo Salgueiro , "Paul E. Jones" Thread-Topic: [webfinger] Renaming the "resource" parameter Thread-Index: Ac4Fc+OnNsp5F4zbTTKegp3x/gh3ywAAiksAAA2jg7A= Date: Fri, 8 Feb 2013 03:30:31 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436741EF06@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <008801ce0574$7373d7c0$5a5b8740$@packetizer.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: text/plain; charset="us-ascii" 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:(24454001)(199002)(189002)(377454001)(51704002)(13464002)(23726001)(50986001)(65816001)(16406001)(47446002)(63696002)(55846006)(76482001)(56776001)(59766001)(51856001)(46102001)(47736001)(47976001)(54316002)(5343655001)(56816002)(47776003)(20776003)(5343635001)(4396001)(79102001)(54356001)(77982001)(53806001)(74502001)(49866001)(46406002)(74662001)(50466001)(80022001)(31966008)(44976002)(33656001)(66066001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB023; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0751474A44 Cc: "webfinger@ietf.org" , "webfinger@googlegroups.com" Subject: Re: [webfinger] Renaming the "resource" parameter 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, 08 Feb 2013 03:30:45 -0000 I wouldn't rename it at this point "resource" is fine. -- Mike -----Original Message----- From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Beh= alf Of Gonzalo Salgueiro Sent: Thursday, February 07, 2013 1:00 PM To: Paul E. Jones Cc: webfinger@ietf.org; webfinger@googlegroups.com Subject: Re: [webfinger] Renaming the "resource" parameter At this point "resource" is cemented in my mind as the name for the paramet= er. My preference is to stick with it. Using quotes seems a sufficient c= larification of its usage as a parameter. Gonzalo On Feb 7, 2013, at 3:48 PM, Paul E. Jones wrote: > Folks, > =20 > In the most recent round of edits (I hope to publish tomorrow) I made a p= ass through the text to try to use the word "resource" or "WebFinger resour= ce" rather than "WebFinger server" where it made sense. ("Server" is still= used, but hopefully only when speaking of the web server itself.) > =20 > But, as I did that, I noticed that in at least one place the word "resour= ce" (referring to the parameter that gets passed in) seemed to make the tex= t confusing. I put quotes around "resource" when I'm referring to the para= meter. > =20 > The question is this: should we rename the "resource" parameter to someth= ing else? > =20 > SWD used "principal" and the JRD uses the term "subject". I think either= of those would work as alternatives. > =20 > Or, shall we continue with "resource"? I think it's worded so that it's = not confusing now, but I'm probably a poor judge of that since I know is me= ant. > =20 > Paul > =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 From bradfitz@google.com Thu Feb 7 20:00: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 382EE1F0D08 for ; Thu, 7 Feb 2013 20:00:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id otyYhnQp2ahO for ; Thu, 7 Feb 2013 20:00:03 -0800 (PST) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) by ietfa.amsl.com (Postfix) with ESMTP id 279BC1F0D05 for ; Thu, 7 Feb 2013 20:00:03 -0800 (PST) Received: by mail-wg0-f45.google.com with SMTP id dq12so2672327wgb.24 for ; Thu, 07 Feb 2013 20:00:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=GG/fg/IbttyepqWAv5YUqE6D4OmkEr9Nrl1y2mD3OIs=; b=dvR2u3h1BVhDYOghZwXRqC8tufSapf9iM/TlEepf1UpJehRtNQUJDcCSPXqGegekeP 5e70RuFvLdyK8LZ2Ud7kyVpemgFBPoKTnkbxWKav3S3TkYx/84gZ2htnnZCslSDWExZQ z7Z8AE0fopE8dsOekqqZGqGABrzsS315zGVY1RJ1SkoNMSnbrqUsU8+YYeSSJIY+wrAM VZjitbggk7RkYio1I72hI7aBa6zJLoXp2SneRwQAFVKS7Y1utyJkrU6daC9wzN+WdwsW HxtDt9VaUP+jWQuq4V4/sHE5ewcSsVFsirmPlPGkCuNHEKTduLztdbGuuI5wtDifUDH/ BgSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=GG/fg/IbttyepqWAv5YUqE6D4OmkEr9Nrl1y2mD3OIs=; b=fqYEa26GPxbrQSegZK+HgcepZchWj8+1S1xUw3/M3l2+/O1HOk3ZQNvcDu5FY8J1jl 1wBKlGvcb1wnMUvTCA8p+dXPvYX/lDfkqXAwylkanCoVEnGpBcBc5LerkD4H5CUxTLud EMuYGnOYkDqMsI5TE26E2bcwH0SO+JOLs8CRyy+cfRjWsKV/ZIFIYyecmmOkms8Fxz8E R+d4HaxICo0q5hro77YwFKapSas8JDN/MHuRLA05AYceBPCyjrrOU/fDOFa5ZeTDJ6gS vKW22v01hK5yzOKcpa53xrKpDwhdQ7/OMz3Pge6Qarp+GMxs2KuYp62Gv7Hpao+w76Lz Lhiw== MIME-Version: 1.0 X-Received: by 10.180.102.7 with SMTP id fk7mr6700913wib.27.1360296002259; Thu, 07 Feb 2013 20:00:02 -0800 (PST) Received: by 10.194.62.98 with HTTP; Thu, 7 Feb 2013 20:00:02 -0800 (PST) In-Reply-To: <368FB88B-7179-4428-A08A-C7201B8B4EF2@gmail.com> References: <072501ce04f7$feee5af0$fccb10d0$@packetizer.com> <632DD91F-6715-473D-81EE-8C58686B13BA@gmail.com> <368FB88B-7179-4428-A08A-C7201B8B4EF2@gmail.com> Date: Thu, 7 Feb 2013 20:00:02 -0800 Message-ID: From: Brad Fitzpatrick To: Dick Hardt Content-Type: multipart/alternative; boundary=f46d0444e7d7010aa204d52e9890 X-Gm-Message-State: ALoCoQniaUnI7Fn9TPNr1Pt22viAe+v4d0eij3T7I292Sofc3wKMtykVig3hBJSJeDW6e6VRIew/a2TUHQQcE3ZQsTeXRu+gXeHWcVIKa1jLVEOxBuIDohhUFWCm6eQTEFGa3o2MqAtcPwzmqViDSIDWnP6garr3Lkw6BYXd8T/lZRGMMHM//cgigIyR9rlzTjQxULaui1dD Cc: "webfinger@ietf.org" , Barry Leiba , Tim Bray , "Paul E. Jones" Subject: Re: [webfinger] Media type for 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, 08 Feb 2013 04:00:04 -0000 --f46d0444e7d7010aa204d52e9890 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Feb 7, 2013 at 4:17 PM, Dick Hardt wrote: > > On Feb 7, 2013, at 9:17 AM, Tim Bray wrote: > > On Thu, Feb 7, 2013 at 9:02 AM, Dick Hardt wrote: > >> Barry >> >> To help the less knowledgeable such as myself, would you be kind enough >> to point out some examples of similar protocols that are widely deployed >> that defined a new media type? >> > > I=E2=80=99ve got a better idea; why don=E2=80=99t we just stop arguing ov= er this stupid > bikeshed issue and do what our AD just asked us to do. > > > I apologize for coming in late on this conversation and if it has been > discussed significantly already. > > Speaking as a developer, having a media type other than application/json > looks to cause me a bunch of hassle. When writing a server, I would have = to > explicitly set the header rather than just writing a JSON object and > letting my server to the right thing, and when writing a client, my > libraries will give me a parsed object automatically if it is > application/json. I already know if I am serving or requesting Web Finger > data, so I am confused about the value I would get as a developer having = a > media type other than application/json. > You should set it explicitly anyway so your server doesn't sniff incorrectly on weird or malicious input. Imagine the server also has a future CRUD API. As a malicious peer server OAuthing adding new links to a victim, I just have to get some HTML in the first 512 bytes to trick your sniffer and then other links can have JavaScript/XSS payloads. --f46d0444e7d7010aa204d52e9890 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Feb 7, 2013 at 4:17 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

On Feb 7, 2013, at 9:17 AM, Tim Bray <tbray@text= uality.com> wrote:

On Thu, Feb 7, 2013 at 9:02 = AM, Dick Hardt <dick.hardt@gmail.com> wr= ote:
Barry

To help the less knowledgeable such as myself, would you be kind enough to = point out some examples of similar protocols that are widely deployed that = defined a new media type?

I=E2=80=99ve = got a better idea; why don=E2=80=99t we just stop arguing over this stupid = bikeshed issue and do what our AD just asked us to do.

I apologize for c= oming in late on this conversation and if it has been discussed significant= ly already.

Speaking as a developer, having a medi= a type other than application/json looks to cause me a bunch of hassle. Whe= n writing a server, I would have to explicitly set the header rather than j= ust writing a JSON object and letting my server to the right thing, and whe= n writing a client, my libraries will give me a parsed object automatically= if it is application/json. I already know if I am serving or requesting We= b Finger data, so I am confused about the value I would get as a developer = having a media type other than application/json.

You should set it explicitly a= nyway so your server doesn't sniff incorrectly on weird or malicious in= put.

Imagine the server also has a fut= ure CRUD API. =C2=A0As a malicious peer server OAuthing adding new links to= a victim, I just have to get some HTML in the first 512 bytes to trick you= r sniffer and then other links can have JavaScript/XSS payloads.

--f46d0444e7d7010aa204d52e9890-- From evan@e14n.com Fri Feb 8 06:29:17 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 9D74021F8A4B for ; Fri, 8 Feb 2013 06:29:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yStLpXXpHjm for ; Fri, 8 Feb 2013 06:29:16 -0800 (PST) Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id A52DE21F8A48 for ; Fri, 8 Feb 2013 06:29:16 -0800 (PST) Received: from [192.168.0.107] (modemcable218.194-202-24.mc.videotron.ca [24.202.194.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id B4BAE8D4505; Fri, 8 Feb 2013 14:43:20 +0000 (UTC) Message-ID: <51150BB8.2050601@e14n.com> Date: Fri, 08 Feb 2013 09:29:12 -0500 From: Evan Prodromou Organization: E14N User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Paul E. Jones" References: <006601ce0571$c2b9c180$482d4480$@packetizer.com> In-Reply-To: <006601ce0571$c2b9c180$482d4480$@packetizer.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060609020500010808090602" Cc: webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] The "expires" member of the JRD 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, 08 Feb 2013 14:29:17 -0000 This is a cryptographically signed message in MIME format. --------------ms060609020500010808090602 Content-Type: multipart/alternative; boundary="------------010208060807050309090708" This is a multi-part message in MIME format. --------------010208060807050309090708 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Unless there are earth-shatteringly critical problems with the spec, I=20 feel like it's time to ship what we've got. The presence or absence of the optional "expires" element in JRD is of=20 microscopic importance; let's get this thing out. -Evan On 13-02-07 03:28 PM, Paul E. Jones wrote: > > Folks, > > Questions have been raised about the "expires" member of the JRD two=20 > or three times now, with concerns related to the fact that HTTP has=20 > multiple ways of also indicating how long a resource representation=20 > should be cached. > > This element is exists for historical reason, but it's not clear to me = > if anyone is using it or cares to use it. > > Shall we keep it or just remove it from the spec entirely? > > Paul > > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger --------------010208060807050309090708 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Unless there are earth-shatteringly critical problems with the spec, I feel like it's time to ship what we've got.

The presence or absence of the optional "expires" element in JRD is of microscopic importance; let's get this thing out.

-Evan

On 13-02-07 03:28 PM, Paul E. Jones wrote:

Folks,

 

Questions have been raised about the “expires” member of the JRD two or three times now,= with concerns related to the fact that HTTP has multiple ways of also indicating how long a resource representation should be cached.

 

This element is exists for historical reason, but it’s not clear to me if anyone is using it or= cares to use it.

 

Shall we keep it or just remove it from th= e spec entirely?

 

Paul

 



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

--------------010208060807050309090708-- --------------ms060609020500010808090602 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMQTCC BUswggQzoAMCAQICEEuui3coSgPxeBmm1kzS1rswDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAe Fw0xMjExMjEwMDAwMDBaFw0xMzExMjEyMzU5NTlaMIIBDjEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52 ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMp OTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJ RCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRcwFQYDVQQDFA5FdmFuIFByb2Ry b21vdTEcMBoGCSqGSIb3DQEJARYNZXZhbkBlMTRuLmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAORmFCsNPJqt5UyhR02QZdZdUxvxQcPqu4jsZ6OEHSN5B+fUGFp87FLq 4PJZwfIu1Cv4QItq4AmIvVJi8AbrbBBNN45jzZvPNFCA7lvihd47aviNpfOdm0mx3YYfH+aU 4W5oXdSrCaIqWwAjxUnYWaJljCXi7kd9t4zL9mnl+W+IKw3L5sT2CWZpapAmCI+xO41PhLEJ hyBWrQKgSwjINgJgoEVOhVien2v5pe3FxWGDRuS3UWiRHFPg+ZjmQIvmR6KJ5l3esRl7y1L2 QbNGlSC92LAW1MXDSo5T0WCypZs93NFBvcfsOcdWVBS+1p1gycpGtkDio5Itgqv2IzBA8c0C AwEAAaOB0jCBzzAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggr BgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMFAGA1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9p bmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELUczLmNy bDANBgkqhkiG9w0BAQUFAAOCAQEAPaHFMHt2vp6k7gmYqDdvn1upM2aJ2sVX4ybGJME97Hrg /axsoTmtY69LtfTNHqOJAbjXgaqABXp9f+p1JqzI5Nkaac2rWDx2BFGUdUuQKeIzyiAPJ0Ou wWNBThLS/tTUuipWx2V0jIJzPRP0gZuxBi6JQydnLsWEMZeup5jC8QhXCSPu1aaJ08SbdYCD xYSpHUoPkpOxm7A/Vx4xN24edU0TvmH+xvXPMo3NgPNs+Qsjt2Tugg2O6XngESdsE/X9+JMC aDRyDaC1oUe8TytFkOJvJ2AplXVwr5h3pI3IoDoq1EX86MZjf3QiloN2Qn0ELsIRcPkQZPeM +O2qklmEJTCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEFBQAw gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4g LSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQ dWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAw MDAwMFoXDTE5MDQzMDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2ln biwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVy bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJ bmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAO3ER98qKB18Bmu71yEyyWwTj+mxjUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBf DUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliWB6+eFBgHT1q9n9IxslQZc0ZqGUIR7BJzIY31 3DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGcedAATDdCG2pNn+DMDrho8a2l49sAsjuGD P3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69ssQRevsG2lC2XkC0n0rse6YNqhPbE sq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOMWev7btVCxL5Bx/UCAwEAAaOC ArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AudmVyaXNp Z24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtghkgBhvhFAQcXATBW MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoGCCsGAQUFBwIC MB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCegJYYjaHR0 cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4GCCsG AQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy7 0FI4mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAu BgNVHREEJzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4E FgQUeUdhCEH9OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRo b3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmlt YXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0G CSqGSIb3DQEBBQUAA4IBAQA5Tc9BmYG1qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGT gc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN7/HSgZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw8 4J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqTOtWuEnAI6/s74nfs6CtkNXbNutrg0csU1nFY m77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih/1yybUneZVJC+w6I0u1KHb9L4/jMcvpI DmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0DuFUWjMZoA+ciqHMLsbyg2lJY3QoO f8GCMYIE+TCCBPUCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMg b2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsT FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQS66LdyhKA/F4GabWTNLWuzAJBgUrDgMCGgUA oIIC2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzAyMDgx NDI5MTJaMCMGCSqGSIb3DQEJBDEWBBRS1D8q+6ZP1Z5WV7wYHh8CgM+ffDBsBgkqhkiG9w0B CQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVz ZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJz b25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzMCEEuui3coSgPxeBmm1kzS1rswggEFBgsqhkiG9w0BCRAC CzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQg aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEczAhBLrot3KEoD8XgZptZM0ta7MA0GCSqGSIb3DQEBAQUABIIBAFaF g3v6Ch6EkuV34+LdgyxjB6wNZnuiJrhKVITdE83mC/hpEz6gFQpWb643K0lKAP4ONmZNXfpj cAmvr1Xcfy2FLjRGiYM4rSs0BUHqxvzXxxwQF9zrqttGG3eOjh1aOYsd687mdWlQUNU6/XkB KjgTGHk42YgK1mLAuPjEqZpwovojn5DvjcpRerYA0CNoJHtW3lzgYRQAdBpt9oCN8EXQGK5Y Misf9gkue4/USkfKvM308daByNzejCZJ94uKCCGf+wU8N+pWBb7OuSNhoWJF/JyL2DnB9QRE hp82xehguSmu0FNn+PBXT2Yfdq713GqJyXMg3bYYGz6F5/UAzxYAAAAAAAA= --------------ms060609020500010808090602-- From evan@status.net Fri Feb 8 06:29:50 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 1F83B21F8A4A for ; Fri, 8 Feb 2013 06:29:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3Y7n8H-BtIf for ; Fri, 8 Feb 2013 06:29:49 -0800 (PST) Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id 0BCCC21F8A48 for ; Fri, 8 Feb 2013 06:29:49 -0800 (PST) Received: from [192.168.0.107] (modemcable218.194-202-24.mc.videotron.ca [24.202.194.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id 1E18A8D454D; Fri, 8 Feb 2013 14:43:56 +0000 (UTC) Message-ID: <51150BDC.3040100@status.net> Date: Fri, 08 Feb 2013 09:29:48 -0500 From: Evan Prodromou User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Paul E. Jones" References: <008801ce0574$7373d7c0$5a5b8740$@packetizer.com> In-Reply-To: <008801ce0574$7373d7c0$5a5b8740$@packetizer.com> Content-Type: multipart/alternative; boundary="------------080305000403080606020504" Cc: webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] Renaming the "resource" parameter 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, 08 Feb 2013 14:29:50 -0000 This is a multi-part message in MIME format. --------------080305000403080606020504 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit -1, it's good enough, no change. -Evan On 13-02-07 03:48 PM, Paul E. Jones wrote: > > Folks, > > In the most recent round of edits (I hope to publish tomorrow) I made > a pass through the text to try to use the word "resource" or > "WebFinger resource" rather than "WebFinger server" where it made > sense. ("Server" is still used, but hopefully only when speaking of > the web server itself.) > > But, as I did that, I noticed that in at least one place the word > "resource" (referring to the parameter that gets passed in) seemed to > make the text confusing. I put quotes around "resource" when I'm > referring to the parameter. > > The question is this: should we rename the "resource" parameter to > something else? > > SWD used "principal" and the JRD uses the term "subject". I think > either of those would work as alternatives. > > Or, shall we continue with "resource"? I think it's worded so that > it's not confusing now, but I'm probably a poor judge of that since I > know is meant. > > Paul > > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger --------------080305000403080606020504 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
-1, it's good enough, no change.

-Evan

On 13-02-07 03:48 PM, Paul E. Jones wrote:

Folks,

 

In the most recent round of edits (I hope to publish tomorrow) I made a pass through the text to try to use the word “resource” or “WebFinger resource” rather than “WebFinger server” where it made sense.  (“Server” is still used, but hopefully only when speaking of the web server itself.)

 

But, as I did that, I noticed that in at least one place the word “resource” (referring to the parameter that gets passed in) seemed to make the text confusing.  I put quotes around “resource” when I’m referring to the parameter.

 

The question is this: should we rename the “resource” parameter to something else?

 

SWD used “principal” and the JRD uses the term “subject”.  I think either of those would work as alternatives.

 

Or, shall we continue with “resource”?  I think it’s worded so that it’s not confusing now, but I’m probably a poor judge of that since I know is meant.

 

Paul

 



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

--------------080305000403080606020504-- From paulej@packetizer.com Fri Feb 8 07:00: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 8152421F8A4E for ; Fri, 8 Feb 2013 07:00:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qNF8e1STrbNx for ; Fri, 8 Feb 2013 07:00:28 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 8304E21F8554 for ; Fri, 8 Feb 2013 07:00:28 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r18F0Qt3001644 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 8 Feb 2013 10:00:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1360335627; bh=Cd9EKxpEdOh48Bs+o53eZHF2R+RjyEiHKULMS1W4pwU=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=RRfTy2/dKjrWB0jcDnGeFoWrSp+Fpe0OaF7fxjyGkKL+FitBsYi4x4NrnSQ1v3PIi 55zAPJsQm+D/xfUO8ieWGP6B5HmyzTez6yAr9GfsIexCkHZO1am240x1z+giWDWqVc fHyQmwSWiurO9QW6NYVst6H5WrcZv7SzhcoDt7ts= From: "Paul E. Jones" To: "'Evan Prodromou'" References: <008801ce0574$7373d7c0$5a5b8740$@packetizer.com> <51150BDC.3040100@status.net> In-Reply-To: <51150BDC.3040100@status.net> Date: Fri, 8 Feb 2013 10:00:32 -0500 Message-ID: <008001ce060d$0b0f0bc0$212d2340$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0081_01CE05E3.223B4DB0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGCu5qZCednExcaIN5BagNxK7Ly5gH2HaHBmPbx5gA= Content-Language: en-us Cc: webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] Renaming the "resource" parameter 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, 08 Feb 2013 15:00:32 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0081_01CE05E3.223B4DB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Ok, we'll leave the parameter name alone. From: Evan Prodromou [mailto:evan@status.net] Sent: Friday, February 08, 2013 9:30 AM To: Paul E. Jones Cc: webfinger@ietf.org; webfinger@googlegroups.com Subject: Re: [webfinger] Renaming the "resource" parameter -1, it's good enough, no change. -Evan On 13-02-07 03:48 PM, Paul E. Jones wrote: Folks, In the most recent round of edits (I hope to publish tomorrow) I made a pass through the text to try to use the word "resource" or "WebFinger resource" rather than "WebFinger server" where it made sense. ("Server" is still used, but hopefully only when speaking of the web server itself.) But, as I did that, I noticed that in at least one place the word "resource" (referring to the parameter that gets passed in) seemed to make the text confusing. I put quotes around "resource" when I'm referring to the parameter. The question is this: should we rename the "resource" parameter to something else? SWD used "principal" and the JRD uses the term "subject". I think either of those would work as alternatives. Or, shall we continue with "resource"? I think it's worded so that it's not confusing now, but I'm probably a poor judge of that since I know is meant. Paul _______________________________________________ webfinger mailing list webfinger@ietf.org https://www.ietf.org/mailman/listinfo/webfinger ------=_NextPart_000_0081_01CE05E3.223B4DB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ok, we’ll leave = the parameter name alone.

 

From: Evan Prodromou [mailto:evan@status.net]
Sent: Friday, = February 08, 2013 9:30 AM
To: Paul E. Jones
Cc: = webfinger@ietf.org; webfinger@googlegroups.com
Subject: Re: = [webfinger] Renaming the "resource" = parameter

 

-1, = it's good enough, no change.

-Evan

On 13-02-07 03:48 PM, = Paul E. Jones wrote:

Folks,

 

In the most = recent round of edits (I hope to publish tomorrow) I made a pass through = the text to try to use the word “resource” or = “WebFinger resource” rather than “WebFinger = server” where it made sense.  (“Server” is still = used, but hopefully only when speaking of the web server = itself.)

 

But, as I did that, I noticed that in at least one = place the word “resource” (referring to the parameter that = gets passed in) seemed to make the text confusing.  I put quotes = around “resource” when I’m referring to the = parameter.

 

The question is this: should we rename the = “resource” parameter to something else?

 

SWD used = “principal” and the JRD uses the term = “subject”.  I think either of those would work as = alternatives.

 

Or, shall we continue with = “resource”?  I think it’s worded so that = it’s not confusing now, but I’m probably a poor judge of = that since I know is meant.

 

Paul

 




__________________=
_____________________________
webfinger mailing =
list
webfinger@ietf.org
https://www.ietf=
.org/mailman/listinfo/webfinger

 

------=_NextPart_000_0081_01CE05E3.223B4DB0-- From paulej@packetizer.com Fri Feb 8 07:14:50 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 C4B8121F8A8E for ; Fri, 8 Feb 2013 07:14:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxnbtmZVB2fD for ; Fri, 8 Feb 2013 07:14:48 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 94B6821F8A89 for ; Fri, 8 Feb 2013 07:14:48 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r18FEkrY002357 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 8 Feb 2013 10:14:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1360336487; bh=7s07vyuwv7R8+L2GGLHQrqNt6mKtA16+Ae8zVpRA1AI=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=qTeqRfpjupDiBx6asNMLm/QbGjtq8V/429Kz2GgbGPI+2qWLI+HKgxlO/fb88P/WH v6TD7CKa+jqmf988Em6D4HVooR+GDa+88DiEDVxNnwUGHc9xCUJoTn5vh4P+QsfKhR BqQyAOVmL0vMTsO71bNtG1HaiFFqCSvrnzfBP3BA= From: "Paul E. Jones" To: "'Evan Prodromou'" References: <006601ce0571$c2b9c180$482d4480$@packetizer.com> <51150BB8.2050601@e14n.com> In-Reply-To: <51150BB8.2050601@e14n.com> Date: Fri, 8 Feb 2013 10:14:52 -0500 Message-ID: <009001ce060f$0b75f900$2261eb00$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0091_01CE05E5.22A08D40" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKXfMoCXAlmI/1utHC7TAWtthn92QLuvek0lsWqrqA= Content-Language: en-us Cc: webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] The "expires" member of the JRD 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, 08 Feb 2013 15:14:50 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0091_01CE05E5.22A08D40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit It took me only few seconds to remove. If nobody is using it, I agree we should remove it. I'll get out a new version within 12 hours. Paul From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Behalf Of Evan Prodromou Sent: Friday, February 08, 2013 9:29 AM To: Paul E. Jones Cc: webfinger@ietf.org; webfinger@googlegroups.com Subject: Re: [webfinger] The "expires" member of the JRD Unless there are earth-shatteringly critical problems with the spec, I feel like it's time to ship what we've got. The presence or absence of the optional "expires" element in JRD is of microscopic importance; let's get this thing out. -Evan On 13-02-07 03:28 PM, Paul E. Jones wrote: Folks, Questions have been raised about the "expires" member of the JRD two or three times now, with concerns related to the fact that HTTP has multiple ways of also indicating how long a resource representation should be cached. This element is exists for historical reason, but it's not clear to me if anyone is using it or cares to use it. Shall we keep it or just remove it from the spec entirely? Paul _______________________________________________ webfinger mailing list webfinger@ietf.org https://www.ietf.org/mailman/listinfo/webfinger ------=_NextPart_000_0091_01CE05E5.22A08D40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It took me only few = seconds to remove.  If nobody is using it, I agree we should remove = it.

 

I’ll get out a new = version within 12 hours.

 

Paul

 

From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] = On Behalf Of Evan Prodromou
Sent: Friday, February 08, = 2013 9:29 AM
To: Paul E. Jones
Cc: = webfinger@ietf.org; webfinger@googlegroups.com
Subject: Re: = [webfinger] The "expires" member of the = JRD

 

Unless = there are earth-shatteringly critical problems with the spec, I feel = like it's time to ship what we've got.

The presence or absence of = the optional "expires" element in JRD is of microscopic = importance; let's get this thing out.

-Evan

On 13-02-07 = 03:28 PM, Paul E. Jones wrote:

Folks,

 

Questions = have been raised about the “expires” member of the JRD two = or three times now, with concerns related to the fact that HTTP has = multiple ways of also indicating how long a resource representation = should be cached.

 

This element = is exists for historical reason, but it’s not clear to me if = anyone is using it or cares to use it.

 

Shall we = keep it or just remove it from the spec entirely?

 

Paul

 




__________________=
_____________________________
webfinger mailing =
list
webfinger@ietf.org
https://www.ietf=
.org/mailman/listinfo/webfinger

 

------=_NextPart_000_0091_01CE05E5.22A08D40-- From matake@gmail.com Fri Feb 8 07:32: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 55C1221F854D for ; Fri, 8 Feb 2013 07:32:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJUhvBz8UjNn for ; Fri, 8 Feb 2013 07:32:52 -0800 (PST) Received: from mail-da0-f49.google.com (mail-da0-f49.google.com [209.85.210.49]) by ietfa.amsl.com (Postfix) with ESMTP id 894CB21F8528 for ; Fri, 8 Feb 2013 07:32:52 -0800 (PST) Received: by mail-da0-f49.google.com with SMTP id t11so1835828daj.36 for ; Fri, 08 Feb 2013 07:32:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=GTvaeExyKJnHMejSF4GuwC8LlZc1yuMAY1IQ51pD6UU=; b=GKPsyB6yWj4cg0SNyNVwWYI1KZax03mDTJm6cceN7PW7vdX96AnHEjYZDnBUm26KvX XcSSVkaRPm4i+/7XgCGe+z859WkpOQqEXuYckfb5J98gUneuuxhIt9JvHykU/w1OpYZG LR9Dyx6d4GWWykb6szAITwx2/X6plLWvrvsrKAXN6KJNrCnLBcdZ3KL644m+VbOJAAFn 7Y7CSl72NQaTsKIG9VvxHvQZUoyxhUiUEQpyca5tvVjkQXIP3zNGQeQMi8CvzVlhhXg8 3wz55giT2w+Nf48eeRsWGX73aPV2aZzzT0yEenKKMRUMLaJjoAYewKsAsBvxezaUYj+V y1sg== X-Received: by 10.66.80.162 with SMTP id s2mr18241154pax.61.1360337571871; Fri, 08 Feb 2013 07:32:51 -0800 (PST) Received: from [192.168.1.31] (ac149127.dynamic.ppp.asahi-net.or.jp. [183.77.149.127]) by mx.google.com with ESMTPS id q4sm55265163paz.20.2013.02.08.07.32.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Feb 2013 07:32:50 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_3D0622D2-9372-425C-95F1-D91FE3928562" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: nov matake In-Reply-To: <009001ce060f$0b75f900$2261eb00$@packetizer.com> Date: Sat, 9 Feb 2013 00:32:39 +0900 Message-Id: <4C597C37-287A-4F4C-AC7E-78CEA72FC6BE@gmail.com> References: <006601ce0571$c2b9c180$482d4480$@packetizer.com> <51150BB8.2050601@e14n.com> <009001ce060f$0b75f900$2261eb00$@packetizer.com> To: "Paul E. Jones" X-Mailer: Apple Mail (2.1499) Cc: 'Evan Prodromou' , webfinger@ietf.org, webfinger@googlegroups.com Subject: Re: [webfinger] The "expires" member of the JRD 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, 08 Feb 2013 15:32:53 -0000 --Apple-Mail=_3D0622D2-9372-425C-95F1-D91FE3928562 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-2022-jp My webfinger ruby gem is using "expires" parameter for built-in caching = mechanism, but I think it's not too late to remove the functionality from my = library. So I'm +1 for simplifying spec by removing it. ps. It tooks few minutes to remove them from my gem :p On 2013/02/09, at 0:14, "Paul E. Jones" wrote: > It took me only few seconds to remove. If nobody is using it, I agree = we should remove it. > =20 > I=1B$B!G=1B(Bll get out a new version within 12 hours. > =20 > Paul > =20 > From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] = On Behalf Of Evan Prodromou > Sent: Friday, February 08, 2013 9:29 AM > To: Paul E. Jones > Cc: webfinger@ietf.org; webfinger@googlegroups.com > Subject: Re: [webfinger] The "expires" member of the JRD > =20 > Unless there are earth-shatteringly critical problems with the spec, I = feel like it's time to ship what we've got. >=20 > The presence or absence of the optional "expires" element in JRD is of = microscopic importance; let's get this thing out. >=20 > -Evan >=20 > On 13-02-07 03:28 PM, Paul E. Jones wrote: > Folks, > =20 > Questions have been raised about the =1B$B!H=1B(Bexpires=1B$B!I=1B(B = member of the JRD two or three times now, with concerns related to the = fact that HTTP has multiple ways of also indicating how long a resource = representation should be cached. > =20 > This element is exists for historical reason, but it=1B$B!G=1B(Bs not = clear to me if anyone is using it or cares to use it. > =20 > Shall we keep it or just remove it from the spec entirely? > =20 > Paul > =20 >=20 >=20 >=20 > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > =20 > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger --Apple-Mail=_3D0622D2-9372-425C-95F1-D91FE3928562 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-2022-jp
My webfinger ruby gem is = using "expires" parameter for built-in caching mechanism,
but = I think it's not too late to remove the functionality from my = library.
So I'm +1 for simplifying spec by removing = it.

ps.
It tooks few minutes to = remove them from my gem :p

On 2013/02/09, at 0:14, = "Paul E. Jones" <paulej@packetizer.com> = wrote:

It took me only few seconds to remove.  If = nobody is using it, I agree we should remove = it.
 
I=1B$B!G=1B(Bll get out a new = version within 12 hours.
 
 
From: webfinger-bounces@ietf.org = [mailto:webfinger-bounces@ietf.org] On Behalf Of Evan = Prodromou
Sent: Friday, February 08, 2013 = 9:29 AM
To: Paul E. = Jones
Cc: webfinger@ietf.org; webfinger@googlegroups.com<= br>Subject: Re: = [webfinger] The "expires" member of the = JRD
Unless there are = earth-shatteringly critical problems with the spec, I feel like it's = time to ship what we've got.

The presence or absence of the = optional "expires" element in JRD is of microscopic importance; let's = get this thing out.

-Evan

On 13-02-07 03:28 PM, Paul E. = Jones wrote:
Folks,
 
This element is = exists for historical reason, but it=1B$B!G=1B(Bs not clear to me if = anyone is using it or cares to use it.
 
Shall = we keep it or just remove it from the spec = entirely?
webfinger mailing list
webfinger@ietf.org
https://www.i=
etf.org/mailman/listinfo/webfinger

= --Apple-Mail=_3D0622D2-9372-425C-95F1-D91FE3928562-- From nov@matake.jp Fri Feb 8 07:37: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 9851821F8A5A for ; Fri, 8 Feb 2013 07:37:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cr9d1qMvTljb for ; Fri, 8 Feb 2013 07:37:32 -0800 (PST) Received: from mail-da0-f47.google.com (mail-da0-f47.google.com [209.85.210.47]) by ietfa.amsl.com (Postfix) with ESMTP id D0C7F21F8717 for ; Fri, 8 Feb 2013 07:37:32 -0800 (PST) Received: by mail-da0-f47.google.com with SMTP id s35so1811775dak.6 for ; Fri, 08 Feb 2013 07:37:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=NgblTNs+2STWS8XNnM4VYwhflV3YaDSMgypvY+gd900=; b=LAcEZaQRGs1Ht4IZcMsPQUEnH20VpjSNdLGBhxOsqfEejdGeE738TXtS8uTYIyFSsa tO7hjeAMBt7zur4zqmXxthrM3arUdjrw7h+zArGN0PBRkMiyxIUVKVx2OPDa7BfxjNEX yjl6/d56HQrvkxl44GcDIZZ3dA1W3IyhWPgPRduu9H3eubCw9w+976qFWelq2ZzzhKRi G4g7vehNbF7/MzAV9CaoZDasTyN7VxSHF0yeWAxmVcvG6dLDHDQsXOJWGWNKnWHr4tv9 AmXqCY6zNJTt6S3tDeMNh8KnxY1ojKNe/Arq3BlN60nTvIH7r+gHQDlV3UeBMXmfYxce mMeQ== X-Received: by 10.66.72.97 with SMTP id c1mr18292274pav.48.1360337852186; Fri, 08 Feb 2013 07:37:32 -0800 (PST) Received: from [192.168.1.31] (ac149127.dynamic.ppp.asahi-net.or.jp. [183.77.149.127]) by mx.google.com with ESMTPS id k7sm41957709paz.13.2013.02.08.07.37.29 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Feb 2013 07:37:31 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_9F9280AD-31D9-4F77-A99F-69FD08FBA80A" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: nov matake In-Reply-To: <51150BB8.2050601@e14n.com> Date: Sat, 9 Feb 2013 00:37:39 +0900 Message-Id: References: <006601ce0571$c2b9c180$482d4480$@packetizer.com> <51150BB8.2050601@e14n.com> To: Evan Prodromou X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQmpNj+zOqv9l+sZEwGDsCoNW2uTnv55sL5pXiFcm8NBheGHuDL4w0yiPU0aiRwiLDozOJYw X-Mailman-Approved-At: Fri, 08 Feb 2013 11:12:00 -0800 Cc: "Paul E. Jones" , webfinger@googlegroups.com, webfinger@ietf.org Subject: Re: [webfinger] The "expires" member of the JRD 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, 08 Feb 2013 15:37:34 -0000 --Apple-Mail=_9F9280AD-31D9-4F77-A99F-69FD08FBA80A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 # Oops, I've replied from wrong email address and rejected by google = groups. # Sending from correct one again. My webfinger ruby gem is using "expires" parameter for built-in caching = mechanism, but I think it's not too late to remove the functionality from my = library. So I'm +1 for simplifying spec by removing it. ps. It tooks few minutes to remove them from my gem :p On 2013/02/08, at 23:29, Evan Prodromou wrote: > Unless there are earth-shatteringly critical problems with the spec, I = feel like it's time to ship what we've got. >=20 > The presence or absence of the optional "expires" element in JRD is of = microscopic importance; let's get this thing out. >=20 > -Evan >=20 > On 13-02-07 03:28 PM, Paul E. Jones wrote: >> Folks, >> =20 >> Questions have been raised about the =93expires=94 member of the JRD = two or three times now, with concerns related to the fact that HTTP has = multiple ways of also indicating how long a resource representation = should be cached. >> =20 >> This element is exists for historical reason, but it=92s not clear to = me if anyone is using it or cares to use it. >> =20 >> Shall we keep it or just remove it from the spec entirely? >> =20 >> Paul >> =20 >>=20 >>=20 >> _______________________________________________ >> webfinger mailing list >> webfinger@ietf.org >> https://www.ietf.org/mailman/listinfo/webfinger >=20 > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger --Apple-Mail=_9F9280AD-31D9-4F77-A99F-69FD08FBA80A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 but I think it's not too = late to remove the functionality from my library.
So I'm +1 for = simplifying spec by removing it.

ps.
It tooks few minutes to = remove them from my gem :p

On 2013/02/08, at 23:29, = Evan Prodromou <evan@e14n.com> = wrote:

=20 =20
Unless there are earth-shatteringly critical problems with the spec, I feel like it's time to ship what we've got.

The presence or absence of the optional "expires" element in JRD is of microscopic importance; let's get this thing out.

-Evan

On 13-02-07 03:28 PM, Paul E. Jones wrote:
=

Folks,

 

Questions = have been raised about the =93expires=94 member of the JRD two or three times now, with concerns related to the fact that HTTP has multiple ways of also indicating how long a resource representation should be cached.

 

This = element is exists for historical reason, but it=92s not clear to me if anyone is using it or cares to use it.

 

Shall we = keep it or just remove it from the spec entirely?

 

Paul

 



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

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

= = --Apple-Mail=_9F9280AD-31D9-4F77-A99F-69FD08FBA80A-- From derhoermi@gmx.net Fri Feb 8 09:46: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 193E121F8AEA for ; Fri, 8 Feb 2013 09:46:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNIRuQHiSz03 for ; Fri, 8 Feb 2013 09:46:13 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id BFF0721F8B1C for ; Fri, 8 Feb 2013 09:46:12 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.30]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0Lvegk-1V0JfL3apg-017U8r for ; Fri, 08 Feb 2013 18:46:11 +0100 Received: (qmail invoked by alias); 08 Feb 2013 17:46:11 -0000 Received: from p57A1EAD5.dip.t-dialin.net (EHLO netb.Speedport_W_700V) [87.161.234.213] by mail.gmx.net (mp030) with SMTP; 08 Feb 2013 18:46:11 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX19fJehjXslfVYevSL+k4T9AtB8vS0RhUH2UyNhggy vvr170OeGCR+Rj From: Bjoern Hoehrmann To: "Paul E. Jones" Date: Fri, 08 Feb 2013 18:46:11 +0100 Message-ID: References: <00c101ce057d$aa4d3300$fee79900$@packetizer.com> In-Reply-To: <00c101ce057d$aa4d3300$fee79900$@packetizer.com> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Mailman-Approved-At: Fri, 08 Feb 2013 11:12:00 -0800 Cc: webfinger@ietf.org, Barry Leiba , media-types@iana.org Subject: Re: [webfinger] [media-types] Media type application/jrd+json 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, 08 Feb 2013 17:46:14 -0000 * Paul E. Jones wrote: >http://tools.ietf.org/html/draft-ietf-appsawg-webfinger >================================================ > >Type name: application > >Subtype name: jrd+json > >Required parameters: N/A > >Optional parameters: N/A > "charset" - Indicates the character set used to encode the JSON Resource > Descriptor. If absent, UTF-8 is assumed. This should say something like "Same as for application/json" or there should be a reason given for why it's different. >Encoding considerations: 8bit This should probably say something like "See RFC 6839, section 3.1.". >Published specification: RFC QQQ (The convention is to use "RFC XXXX".) >Applications that use this media type: WebFinger (That's very brief, I would prefer a proper sentence.) >Fragment identifier considerations: N/A As above, given RFC 6839 it's not clear what this means. >Additional information: > Deprecated alias names for this type: N/A > Magic number(s): N/A > File extension(s): jrd+json Are you sure about having a `+` in file extensions? >Author: Paul E. Jones > >Change controller: Paul E. Jones I haven't checked RFC 4288's successor, but I assume this should more likely be "The IETF." or "The IESG". -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From chris.newman@oracle.com Fri Feb 8 10:53:55 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 601BF21F8B14 for ; Fri, 8 Feb 2013 10:53:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gml76SbazY6V for ; Fri, 8 Feb 2013 10:53:54 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id AB84321F8B13 for ; Fri, 8 Feb 2013 10:53:54 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r18IrTxW028581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Feb 2013 18:53:29 GMT Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r18IrStU004127; Fri, 8 Feb 2013 18:53:28 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from [10.148.206.239] (nifty-silver.us.oracle.com [10.145.239.205]) by gotmail.us.oracle.com (Oracle Communications Messaging Server 7u5-28.16(7.0.5.28.0) 64bit (built Dec 16 2012)) with ESMTPA id <0MHX00F4P0H14200@gotmail.us.oracle.com>; Fri, 08 Feb 2013 10:53:27 -0800 (PST) Date: Fri, 08 Feb 2013 10:53:24 -0800 From: Chris Newman To: "Paul E. Jones" , media-types@iana.org Message-id: <64CAA751B008551D9D7EDC5B@[192.168.15.107]> In-reply-to: <00c101ce057d$aa4d3300$fee79900$@packetizer.com> References: <00c101ce057d$aa4d3300$fee79900$@packetizer.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-Mailman-Approved-At: Fri, 08 Feb 2013 11:12:00 -0800 Cc: webfinger@ietf.org, Barry Leiba Subject: Re: [webfinger] [media-types] Media type application/jrd+json 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, 08 Feb 2013 18:53:55 -0000 The introduction of the "charset" parameter that is not present in the application/json media type makes this incompatible with application/json (since it implicitly allows use of character sets that are not permitted with application/json). As a result, this registration is not compatible with the "+json" suffix. I recommend either removing the charset parameter or changing the name to omit the "+json" suffix. I note the former choice will result in a media type that is simpler to implement. - Chris --On February 7, 2013 16:54:11 -0500 "Paul E. Jones" wrote: > Folks, > > Barry Leiba indicated that we should register the a media type for the > resource representation defined in > http://tools.ietf.org/html/draft-ietf-appsawg-webfinger called the JSON > Resource Descriptor (JRD). > > I am sending this for your review and comments back as we are working to > finalize the draft. > > I have not completed a template for application types before and I see > there are a few new things in the template, so please do let me know if > there is anything that needs clarification or should be changed. > > Thanks, > Paul > > ================================================ > > Type name: application > > Subtype name: jrd+json > > Required parameters: N/A > > Optional parameters: N/A > "charset" - Indicates the character set used to encode the JSON Resource > Descriptor. If absent, UTF-8 is assumed. > > Encoding considerations: 8bit > > Security considerations: > The JSON Resource Descriptor (JRD) is a JavaScript Object Notation > (JSON) object. It is a text format that must be parsed by entities > that wish to utilize the format. Depending on the language and > mechanism used to parse a JSON object, it is possible for an attacker > to inject behavior into a running > program. Therefore, care must be taken to properly parse a received JRD > to > ensure that only a valid JSON object is present and that no JavaScript > code is > injected or executed unexpectedly. > > Interoperability considerations: > This media type is a JavaScript Object Notation (JSON) object and can be > consumed by any software application that can consume JSON objects. > > Published specification: RFC QQQ > > Applications that use this media type: WebFinger > > Fragment identifier considerations: N/A > > Additional information: > Deprecated alias names for this type: N/A > Magic number(s): N/A > File extension(s): jrd+json > Macintosh file type code(s): N/A > > Person & email address to contact for further information: > Paul E. Jones > > Intended usage: COMMON > > Restrictions on usage: N/A > > Author: Paul E. Jones > > Change controller: Paul E. Jones > > Provisional registration? (standards tree only): N/A > > > _______________________________________________ > media-types mailing list > media-types@ietf.org > https://www.ietf.org/mailman/listinfo/media-types > From paulej@packetizer.com Fri Feb 8 11:14:54 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 9379121F8BD1 for ; Fri, 8 Feb 2013 11:14:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.256 X-Spam-Level: X-Spam-Status: No, score=-2.256 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3+8Ot8ioJGj for ; Fri, 8 Feb 2013 11:14:53 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id B067721F8BD4 for ; Fri, 8 Feb 2013 11:14:53 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r18JEQgM016509 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 8 Feb 2013 14:14:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1360350867; bh=qtlKo+DiVoaG0bsMFjCwuMPpWp/mU9GYxjNSaU+C3hc=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Th34klNz5i/2M7Qp9fuVmjRckuaFfWR1dWJOLO6nemtHfxYmRLPu196CWiiAdnIcW KTMxWn4QZn60xRlQuarG+DzXlVmmkgGXIrliYIGTdP/xVfnQrlZDCDC0aqrEB24JhG +huAWCXVJxflijnbTRqtAmVHCIChC+cWVjRaRzew= From: "Paul E. Jones" To: "'Bjoern Hoehrmann'" References: <00c101ce057d$aa4d3300$fee79900$@packetizer.com> In-Reply-To: Date: Fri, 8 Feb 2013 14:14:32 -0500 Message-ID: <015201ce0630$86fe9070$94fbb150$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFrjVDtUGtO0BjHiisI9WYoTvSPaAGmeMp9mSgN5yA= Content-Language: en-us Cc: webfinger@ietf.org, 'Barry Leiba' , media-types@iana.org Subject: Re: [webfinger] [media-types] Media type application/jrd+json 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, 08 Feb 2013 19:14:54 -0000 Bj=F6rn, Thanks for the quick review. I have a couple of questions. > >Optional parameters: N/A > > "charset" - Indicates the character set used to encode the JSON > >Resource > > Descriptor. If absent, UTF-8 is assumed. >=20 > This should say something like "Same as for application/json" or there > should be a reason given for why it's different. Unfortunately, application/json just says "n/a". I changed my text to = say the same, but a question I have is "should we specify 'charset'"? = Without the character set being explicitly specified in the Content-Type header = in the HTTP response, it's not clear to me that we could guarantee proper interpretation. Perhaps it is possible because the only valid encodings = are UTF-8, -16, and -32? =20 > >Fragment identifier considerations: N/A >=20 > As above, given RFC 6839 it's not clear what this means. I have no clue what to put here, honestly. Can you suggest text or = point me to text I can borrow? I'm not aware of a spec that defines how to use = the fragment syntax to dereference part of a JSON object, though some = attempts have been made to define that. Is there something we should use? We certainly can define that within this document, as that is a whole = problem unto itself. =20 > > File extension(s): jrd+json >=20 > Are you sure about having a `+` in file extensions? I have absolutely no preference, though this extension would make it = easier for some using the Apache web server. We could just call it "jrd". I'm = OK with flipping a coin on this one. I have modified the template per your advice, though we might need to = adjust it further based on the answers to the above. I put the updated = template below. Thanks! Paul ------------------------ Type name: application Subtype name: jrd+json Required parameters: N/A Optional parameters: N/A Encoding considerations: See RFC 6839, section 3.1. Security considerations: The JSON Resource Descriptor (JRD) is a JavaScript Object Notation = (JSON) object. It is a text format that must be parsed by entities that wish = to utilize the format. Depending on the language and mechanism used to = parse a JSON object, it is possible for an attacker to inject behavior into = a running program. Therefore, care must be taken to properly parse a received JRD to ensure that only a valid JSON object is present and = that no JavaScript or other code is injected or executed unexpectedly. Interoperability considerations: This media type is a JavaScript Object Notation (JSON) object and can = be consumed by any software application that can consume JSON objects. Published specification: RFC XXXX Applications that use this media type: The JSON Resource Descriptor (JRD) is used by the WebFinger protocol (RFC XXXX) to enable the exchange of information between a client and a WebFinger resource over HTTPS. Fragment identifier considerations: N/A Additional information: Deprecated alias names for this type: N/A Magic number(s): N/A File extension(s): jrd+json Macintosh file type code(s): N/A Person & email address to contact for further information: Paul E. Jones Intended usage: COMMON Restrictions on usage: N/A Author: Paul E. Jones Change controller: IESG has change control over this registration. Provisional registration? (standards tree only): N/A From barryleiba@gmail.com Fri Feb 8 11:16: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 E989921F8BD1 for ; Fri, 8 Feb 2013 11:16:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.922 X-Spam-Level: X-Spam-Status: No, score=-102.922 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GjKnnDH7HGps for ; Fri, 8 Feb 2013 11:16:22 -0800 (PST) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) by ietfa.amsl.com (Postfix) with ESMTP id 6726021F8B81 for ; Fri, 8 Feb 2013 11:16:22 -0800 (PST) Received: by mail-qc0-f170.google.com with SMTP id d42so1571604qca.1 for ; Fri, 08 Feb 2013 11:16:21 -0800 (PST) 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=g+jBA7gmNFXozUdcJmg9I3E73DyGVNgH7QGWTg79Hrw=; b=kZaZ/rf9S3rpipaMnRGB5mu0W5cfpyb/f4VEsMReRfz9HdJJj9zleASTqPY2mJ6emv 0WVM1nBtoc+mdGwo8Sk25+iLzk6cx1K6bmzC2l1XCzVqx/YP6t5lV1fr+YYgqR8EfNEj NPXD+LJP/YdhtxQnKPF6J4vr8PqcxTLyuQRLyUzM5uaM7a2wg30dp1mfBVjfGsQ5hh8P uul2pPR336zAtl2p3lrxfwRvg204LwWcgNyX53XfW3ZlCKm5mz6r+PS02RX8D3e3murf TctnE6VAo1oSZdG2dLbvDA9H1wFYBzopO1zzkyQbP3LakTzQEL2eEb5loL8PZC8sQYyo zgyA== MIME-Version: 1.0 X-Received: by 10.49.118.138 with SMTP id km10mr2679639qeb.18.1360350981232; Fri, 08 Feb 2013 11:16:21 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.49.104.139 with HTTP; Fri, 8 Feb 2013 11:16:21 -0800 (PST) In-Reply-To: <64CAA751B008551D9D7EDC5B@192.168.15.107> References: <00c101ce057d$aa4d3300$fee79900$@packetizer.com> <64CAA751B008551D9D7EDC5B@192.168.15.107> Date: Fri, 8 Feb 2013 14:16:21 -0500 X-Google-Sender-Auth: D_9_fgQa3IKndUktysQvzD_cnFQ Message-ID: From: Barry Leiba To: Chris Newman Content-Type: text/plain; charset=ISO-8859-1 Cc: "Paul E. Jones" , media-types@iana.org, "webfinger@ietf.org" Subject: Re: [webfinger] [media-types] Media type application/jrd+json 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, 08 Feb 2013 19:16:23 -0000 > The introduction of the "charset" parameter that is not present in the > application/json media type makes this incompatible with application/json > (since it implicitly allows use of character sets that are not permitted > with application/json). As a result, this registration is not compatible > with the "+json" suffix. That's a good point: JSON already specifies the encoding, so a charset parameter is not only not necessary, but is actively bad. I agree that eliminating "charset" is best, and I suggest actively noting that it's not allowed, to avoid any question. Perhaps something like this: NEW Optional parameters: None In particular, because RFC 4627 already defines the character encoding for JSON, no "charset" parameter is permitted. END Barry From paulej@packetizer.com Fri Feb 8 11:17:20 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 28CB221F8BEB for ; Fri, 8 Feb 2013 11:17:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.244 X-Spam-Level: X-Spam-Status: No, score=-2.244 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LSvs8L1ILDa6 for ; Fri, 8 Feb 2013 11:17:19 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD7421F8BE2 for ; Fri, 8 Feb 2013 11:17:19 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r18JGsWW016640 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 8 Feb 2013 14:16:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1360351015; bh=t02bhEN7VDU4FoMPio5G3xE1FdzkrNCfMD3KBThd5rg=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=VrQJHHWE9GH0UhKmNzMxxWFbiBlWJC/N/dlHhPri7eGMGBBIIX7TBcQBJhmfwRiob 5j17R6iRgZ0roNEQQk21f5IZBoZMVdTjjzJuvPslDkg7p2n7Iiq/h+VWPhDUMAGorP lCKwJXMGOn0tmbFMXm103acVyibhRIpIufjeIr8Q= From: "Paul E. Jones" To: "'Chris Newman'" , References: <00c101ce057d$aa4d3300$fee79900$@packetizer.com> <64CAA751B008551D9D7EDC5B@[192.168.15.107]> In-Reply-To: <64CAA751B008551D9D7EDC5B@[192.168.15.107]> Date: Fri, 8 Feb 2013 14:17:00 -0500 Message-ID: <015401ce0630$deed3ed0$9cc7bc70$@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: AQFrjVDtUGtO0BjHiisI9WYoTvSPaAMsAnbRmRvm2OA= Content-Language: en-us Cc: webfinger@ietf.org, 'Barry Leiba' Subject: Re: [webfinger] [media-types] Media type application/jrd+json 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, 08 Feb 2013 19:17:20 -0000 OK. I changed it to N/A in the update (to match application/json). Still feels wrong somehow... but, I'll not belabor the point. Paul > -----Original Message----- > From: Chris Newman [mailto:chris.newman@oracle.com] > Sent: Friday, February 08, 2013 1:53 PM > To: Paul E. Jones; media-types@iana.org > Cc: webfinger@ietf.org; Barry Leiba > Subject: Re: [media-types] Media type application/jrd+json > > The introduction of the "charset" parameter that is not present in the > application/json media type makes this incompatible with > application/json (since it implicitly allows use of character sets that > are not permitted with application/json). As a result, this registration > is not compatible with the "+json" suffix. > > I recommend either removing the charset parameter or changing the name > to omit the "+json" suffix. I note the former choice will result in a > media type that is simpler to implement. > > - Chris > > --On February 7, 2013 16:54:11 -0500 "Paul E. Jones" > wrote: > > Folks, > > > > Barry Leiba indicated that we should register the a media type for the > > resource representation defined in > > http://tools.ietf.org/html/draft-ietf-appsawg-webfinger called the > > JSON Resource Descriptor (JRD). > > > > I am sending this for your review and comments back as we are working > > to finalize the draft. > > > > I have not completed a template for application types before and I see > > there are a few new things in the template, so please do let me know > > if there is anything that needs clarification or should be changed. > > > > Thanks, > > Paul > > > > ================================================ > > > > Type name: application > > > > Subtype name: jrd+json > > > > Required parameters: N/A > > > > Optional parameters: N/A > > "charset" - Indicates the character set used to encode the JSON > Resource > > Descriptor. If absent, UTF-8 is assumed. > > > > Encoding considerations: 8bit > > > > Security considerations: > > The JSON Resource Descriptor (JRD) is a JavaScript Object Notation > > (JSON) object. It is a text format that must be parsed by entities > > that wish to utilize the format. Depending on the language and > > mechanism used to parse a JSON object, it is possible for an > attacker > > to inject behavior into a running > > program. Therefore, care must be taken to properly parse a received > > JRD to > > ensure that only a valid JSON object is present and that no > > JavaScript code is > > injected or executed unexpectedly. > > > > Interoperability considerations: > > This media type is a JavaScript Object Notation (JSON) object and > can be > > consumed by any software application that can consume JSON objects. > > > > Published specification: RFC QQQ > > > > Applications that use this media type: WebFinger > > > > Fragment identifier considerations: N/A > > > > Additional information: > > Deprecated alias names for this type: N/A > > Magic number(s): N/A > > File extension(s): jrd+json > > Macintosh file type code(s): N/A > > > > Person & email address to contact for further information: > > Paul E. Jones > > > > Intended usage: COMMON > > > > Restrictions on usage: N/A > > > > Author: Paul E. Jones > > > > Change controller: Paul E. Jones > > > > Provisional registration? (standards tree only): N/A > > > > > > _______________________________________________ > > media-types mailing list > > media-types@ietf.org > > https://www.ietf.org/mailman/listinfo/media-types > > > > > From paulej@packetizer.com Fri Feb 8 11:22:19 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 24D0121F8B62 for ; Fri, 8 Feb 2013 11:22:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kiSNc95hXlQ for ; Fri, 8 Feb 2013 11:22:18 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 7E62121F8B64 for ; Fri, 8 Feb 2013 11:22:18 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r18JLqWs016901 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 8 Feb 2013 14:21:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1360351312; bh=nencWw1Cn9J2ixaNzjN9Bb+OhLKfpxIsWMqHGPx1c2o=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Qpi3QISKznsCAB0zrp8FNC3X9RmSptLZk8l+qLG5hO+x3zdlb++GQfH/50CFgoGaw OOpw1KMcxtVHKa6KWPY9fg4To21Q/j6gBt4Pd2nK8/JFJJ/h1svziIyTTy9IcHAvtt Ci8dY/t4+Nz+oGLmAK65DYBCGIe4b0SmWVj74Zus= From: "Paul E. Jones" To: "'Bjoern Hoehrmann'" References: <00c101ce057d$aa4d3300$fee79900$@packetizer.com> In-Reply-To: Date: Fri, 8 Feb 2013 14:21:57 -0500 Message-ID: <015601ce0631$90470260$b0d50720$@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: AQFrjVDtUGtO0BjHiisI9WYoTvSPaAGmeMp9ApkIMX2ZE0wtoA== Content-Language: en-us Cc: webfinger@ietf.org, 'Barry Leiba' , media-types@iana.org Subject: Re: [webfinger] [media-types] Media type application/jrd+json 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, 08 Feb 2013 19:22:19 -0000 I wrote: > Unfortunately, application/json just says "n/a". I changed my text to > say the same, but a question I have is "should we specify 'charset'"? > Without the character set being explicitly specified in the Content-Type > header in the HTTP response, it's not clear to me that we could > guarantee proper interpretation. Perhaps it is possible because the > only valid encodings are UTF-8, -16, and -32? Scratch that one... Section 3 of RFC 4627 specifies how to guarantee proper interpretation. Paul From paulej@packetizer.com Fri Feb 8 11:26:27 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 C88DE21F8BDB for ; Fri, 8 Feb 2013 11:26:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGmpdJlWPkwU for ; Fri, 8 Feb 2013 11:26:27 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 43A3621F8BE7 for ; Fri, 8 Feb 2013 11:26:27 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r18JQ2kr017136 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 8 Feb 2013 14:26:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1360351562; bh=8S9gT+1eCmXbeLpXUds2Oa653PiQ310XSUpClC8SNio=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=qGGyFuMVUP8hppa/6yxn49qiaQQhkG7NwJMVIbUfSwrxmFc6EArfS929hiYI0PzV/ vgwiPo6HvWegQI8mA2j4zBSb8LNMS9MCNNU4K7U/PmveBu+Dtf6DQHYnz+yiVwT19N OhgWkpwKcKns3QsC70FwJljq995TVarfEzoXQnjA= From: "Paul E. Jones" To: "'Barry Leiba'" , "'Chris Newman'" References: <00c101ce057d$aa4d3300$fee79900$@packetizer.com> <64CAA751B008551D9D7EDC5B@192.168.15.107> In-Reply-To: Date: Fri, 8 Feb 2013 14:26:08 -0500 Message-ID: <015b01ce0632$257ddca0$707995e0$@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: AQFrjVDtUGtO0BjHiisI9WYoTvSPaADexDJ4AlyhwCOZG2258A== Content-Language: en-us Cc: webfinger@ietf.org, media-types@iana.org Subject: Re: [webfinger] [media-types] Media type application/jrd+json 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, 08 Feb 2013 19:26:27 -0000 Barry, > NEW > Optional parameters: None Per RFC 6838, I must put "N/A", not "none". > In particular, because RFC 4627 already defines the character encoding > for JSON, no "charset" parameter is permitted. Do we want to say that the parameter is not permitted or just say that it is not necessary? My web server might make an attempt to add a charset parameter in the Content-Type if I don't explicitly insert one. I've not tested that, but I have seen odd behavior like that before, so I get in the habit of being explicit about it. Paul From dick.hardt@gmail.com Fri Feb 8 11:27:37 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 BF7CC21F8A4F for ; Fri, 8 Feb 2013 11:27:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLCi6757wtdB for ; Fri, 8 Feb 2013 11:27:37 -0800 (PST) Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com [209.85.220.41]) by ietfa.amsl.com (Postfix) with ESMTP id 1D21321F8A4B for ; Fri, 8 Feb 2013 11:27:37 -0800 (PST) Received: by mail-pa0-f41.google.com with SMTP id fb11so2245434pad.28 for ; Fri, 08 Feb 2013 11:27:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=t/8TGV6qnFYOc74sdfU9s2bbQKTTmZ7Vx8qDkfWNKkI=; b=MkejDKg5Ls3fGlQ9hg1ZpU7E7RZG1kYj6aUWbSEWAhq8VlFXXaQGb9WtIO77wzHbfq m7aUuQRuuGle+UQF0SpHnZid9FsnDDzoLUhj6SIDp5KpZGxSjgN1BXnYJAdu29wdPOYl Vl1p6h87Veh0Jd/T/KHmt4cO0Q1Mk9YC68aYandivimIWhzI5o9z6a80AnN3dd3wD92a rk+WyEvYV/NmQWukUBrpDkdJzRwX+BWf0Yz83skiis7wADjaSM1/MQ7Oc+2mMUZT78/3 0rVSwWw6QE4dNH0UVTbI1a3FrS7G2vqLeZmZdPBRFo2+P7fXmw3/0cIyCDgFxWoSV0bE Qo/Q== X-Received: by 10.66.87.67 with SMTP id v3mr20070177paz.63.1360351656575; Fri, 08 Feb 2013 11:27:36 -0800 (PST) Received: from nb003453.idir.bcgov ([142.36.72.186]) by mx.google.com with ESMTPS id z10sm56622437pay.7.2013.02.08.11.27.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Feb 2013 11:27:35 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_829BBC92-03BE-472D-85CF-294C8903C773" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dick Hardt In-Reply-To: Date: Fri, 8 Feb 2013 11:27:33 -0800 Message-Id: References: <072501ce04f7$feee5af0$fccb10d0$@packetizer.com> <632DD91F-6715-473D-81EE-8C58686B13BA@gmail.com> <368FB88B-7179-4428-A08A-C7201B8B4EF2@gmail.com> To: Brad Fitzpatrick X-Mailer: Apple Mail (2.1499) Cc: "webfinger@ietf.org" , Barry Leiba , Tim Bray , "Paul E. Jones" , Dick Hardt Subject: Re: [webfinger] Media type for 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, 08 Feb 2013 19:27:37 -0000 --Apple-Mail=_829BBC92-03BE-472D-85CF-294C8903C773 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Feb 7, 2013, at 8:00 PM, Brad Fitzpatrick = wrote: > On Thu, Feb 7, 2013 at 4:17 PM, Dick Hardt = wrote: >=20 > On Feb 7, 2013, at 9:17 AM, Tim Bray wrote: >=20 >> On Thu, Feb 7, 2013 at 9:02 AM, Dick Hardt = wrote: >> Barry >>=20 >> To help the less knowledgeable such as myself, would you be kind = enough to point out some examples of similar protocols that are widely = deployed that defined a new media type? >>=20 >> I=92ve got a better idea; why don=92t we just stop arguing over this = stupid bikeshed issue and do what our AD just asked us to do. >=20 > I apologize for coming in late on this conversation and if it has been = discussed significantly already. >=20 > Speaking as a developer, having a media type other than = application/json looks to cause me a bunch of hassle. When writing a = server, I would have to explicitly set the header rather than just = writing a JSON object and letting my server to the right thing, and when = writing a client, my libraries will give me a parsed object = automatically if it is application/json. I already know if I am serving = or requesting Web Finger data, so I am confused about the value I would = get as a developer having a media type other than application/json. >=20 > You should set it explicitly anyway so your server doesn't sniff = incorrectly on weird or malicious input. >=20 > Imagine the server also has a future CRUD API. As a malicious peer = server OAuthing adding new links to a victim, I just have to get some = HTML in the first 512 bytes to trick your sniffer and then other links = can have JavaScript/XSS payloads. I agree the content type SHOULD be set explicitly and checked = explicitly. Not having to explicitly set the content type lowers the = barriers to people experimenting -> lower barrier to adoption. =20 -- Dick= --Apple-Mail=_829BBC92-03BE-472D-85CF-294C8903C773 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 bradfitz@google.com> = wrote:

On Thu, Feb 7, 2013 at 4:17 PM, Dick = Hardt <dick.hardt@gmail.com> = wrote:

On Feb 7, = 2013, at 9:17 AM, Tim Bray <tbray@textuality.com> = wrote:

On Thu, Feb 7, 2013 at = 9:02 AM, Dick Hardt <dick.hardt@gmail.com> wrote:
Barry

To help the less knowledgeable such as myself, would you be kind enough = to point out some examples of similar protocols that are widely deployed = that defined a new media type?

I=92ve = got a better idea; why don=92t we just stop arguing over this stupid = bikeshed issue and do what our AD just asked us to do.

I apologize = for coming in late on this conversation and if it has been discussed = significantly already.

Speaking as a developer, = having a media type other than application/json looks to cause me a = bunch of hassle. When writing a server, I would have to explicitly set = the header rather than just writing a JSON object and letting my server = to the right thing, and when writing a client, my libraries will give me = a parsed object automatically if it is application/json. I already know = if I am serving or requesting Web Finger data, so I am confused about = the value I would get as a developer having a media type other than = application/json.

You should set it = explicitly anyway so your server doesn't sniff incorrectly on weird or = malicious input.

Imagine = the server also has a future CRUD API.  As a malicious peer server = OAuthing adding new links to a victim, I just have to get some HTML in = the first 512 bytes to trick your sniffer and then other links can have = JavaScript/XSS = payloads.

I agree the = content type SHOULD be set explicitly and checked explicitly. Not having = to explicitly set the content type lowers the barriers to people = experimenting -> lower barrier to adoption. =  

-- Dick
= --Apple-Mail=_829BBC92-03BE-472D-85CF-294C8903C773-- From dick.hardt@gmail.com Fri Feb 8 11:28: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 B323421F8BCE for ; Fri, 8 Feb 2013 11:28:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4etJv02AXZPS for ; Fri, 8 Feb 2013 11:28:43 -0800 (PST) Received: from mail-da0-f42.google.com (mail-da0-f42.google.com [209.85.210.42]) by ietfa.amsl.com (Postfix) with ESMTP id 17CB621F8BB9 for ; Fri, 8 Feb 2013 11:28:43 -0800 (PST) Received: by mail-da0-f42.google.com with SMTP id z17so1930654dal.1 for ; Fri, 08 Feb 2013 11:28:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=TcTQXeAKhJ9EiTcEVz/YAPyu2knICftjoemQ7aDmUS4=; b=VyWHEO0W2YlJIXnGmNZNZQzUy1nyTaxkafYDUFeJ3mycPC7AW4zw6IlbS7NUZepToM OnWzHUaahKKrn/odlakDGMOz3JrWHqX6RdO0CRbgXy4NY+ZnNRbMx7yBbE9nKFRMUwIx aE6hE5sDcnXQk4fmLgX50mQ1DS7Q2jCbs0EyY/XEqL1CHGDmM2LP9aNZ1yCvdZhDaanx xOpkRWOK+c85wea5xHp/SoTSJlALnjEdcZtcjSwVHz4w9RPt9aWzo/Co5COVmA4AY4Qi 0unkeIc/dCZyAo2ArL/hHJUo68qhOB9APBBT9ldz5IPaRWMudhCf7bmdJQ0c3qMDsVXN A6SA== X-Received: by 10.66.88.37 with SMTP id bd5mr19977386pab.75.1360351722625; Fri, 08 Feb 2013 11:28:42 -0800 (PST) Received: from nb003453.idir.bcgov ([142.36.72.186]) by mx.google.com with ESMTPS id z10sm56635260pay.7.2013.02.08.11.28.39 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Feb 2013 11:28:41 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_81A5D809-4C95-4CBE-B39A-8690CA176D4F" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dick Hardt In-Reply-To: Date: Fri, 8 Feb 2013 11:28:42 -0800 Message-Id: <87117ABE-7DBB-497C-A7AF-ABC8BA303519@gmail.com> References: <072501ce04f7$feee5af0$fccb10d0$@packetizer.com> <632DD91F-6715-473D-81EE-8C58686B13BA@gmail.com> <368FB88B-7179-4428-A08A-C7201B8B4EF2@gmail.com> To: Melvin Carvalho X-Mailer: Apple Mail (2.1499) Cc: "webfinger@ietf.org" , Barry Leiba , Tim Bray , "Paul E. Jones" , Dick Hardt Subject: Re: [webfinger] Media type for 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, 08 Feb 2013 19:28:43 -0000 --Apple-Mail=_81A5D809-4C95-4CBE-B39A-8690CA176D4F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Feb 7, 2013, at 6:37 PM, Melvin Carvalho = wrote: >=20 >=20 > On 8 February 2013 01:17, Dick Hardt wrote: >=20 > On Feb 7, 2013, at 9:17 AM, Tim Bray wrote: >=20 >> On Thu, Feb 7, 2013 at 9:02 AM, Dick Hardt = wrote: >> Barry >>=20 >> To help the less knowledgeable such as myself, would you be kind = enough to point out some examples of similar protocols that are widely = deployed that defined a new media type? >>=20 >> I=92ve got a better idea; why don=92t we just stop arguing over this = stupid bikeshed issue and do what our AD just asked us to do. >=20 > I apologize for coming in late on this conversation and if it has been = discussed significantly already. >=20 > Speaking as a developer, having a media type other than = application/json looks to cause me a bunch of hassle. When writing a = server, I would have to explicitly set the header rather than just = writing a JSON object and letting my server to the right thing, and when = writing a client, my libraries will give me a parsed object = automatically if it is application/json. I already know if I am serving = or requesting Web Finger data, so I am confused about the value I would = get as a developer having a media type other than application/json. >=20 > Hi Dick, thanks for your comments, is this really big hassle, I would = expect maximum one line of code in most programming languages. To my = mind the question lies with interop ... there are many serializations on = the internet, and giving a media type is way to tell a wider audience = what then can expect An extra line of code is another stumbling block for a less experienced = programmer to trip over.=20 JSON is the serialization is it not? I'm unclear on what value being = more specific provides. I'm going to write up some test code to see what the node.js libraries = do with application/jrd+json on the client side. -- Dick= --Apple-Mail=_81A5D809-4C95-4CBE-B39A-8690CA176D4F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 melvincarvalho@gmail.com> = wrote:


On 8 February 2013 = 01:17, Dick Hardt <dick.hardt@gmail.com> = wrote:

On = Feb 7, 2013, at 9:17 AM, Tim Bray <tbray@textuality.com> = wrote:

On Thu, Feb 7, 2013 at 9:02 AM, Dick Hardt <dick.hardt@gmail.com> wrote:
Barry

To help the less knowledgeable such as myself, would you be kind enough = to point out some examples of similar protocols that are widely deployed = that defined a new media type?

I=92ve = got a better idea; why don=92t we just stop arguing over this stupid = bikeshed issue and do what our AD just asked us to do.

I apologize = for coming in late on this conversation and if it has been discussed = significantly already.

Speaking as a developer, = having a media type other than application/json looks to cause me a = bunch of hassle. When writing a server, I would have to explicitly set = the header rather than just writing a JSON object and letting my server = to the right thing, and when writing a client, my libraries will give me = a parsed object automatically if it is application/json. I already know = if I am serving or requesting Web Finger data, so I am confused about = the value I would get as a developer having a media type other than = application/json.

Hi Dick, thanks for your comments, is this = really big hassle, I would expect maximum one line of code in most = programming languages.  To my mind the question lies with interop = ... there are many serializations on the internet, and giving a media = type is way to tell a wider audience what then can = expect

An extra line of code = is another stumbling block for a less experienced programmer to trip = over. 

JSON is the serialization is it = not? I'm unclear on what value being more specific = provides.

I'm going to write up some test code = to see what  the node.js libraries do with application/jrd+json on = the client side.

-- Dick
= --Apple-Mail=_81A5D809-4C95-4CBE-B39A-8690CA176D4F-- From barryleiba@gmail.com Fri Feb 8 11:36:52 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 D22A821F8B81 for ; Fri, 8 Feb 2013 11:36:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.927 X-Spam-Level: X-Spam-Status: No, score=-102.927 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8RsTV37ZpfSg for ; Fri, 8 Feb 2013 11:36:52 -0800 (PST) Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) by ietfa.amsl.com (Postfix) with ESMTP id 4E87321F8A77 for ; Fri, 8 Feb 2013 11:36:52 -0800 (PST) Received: by mail-qc0-f176.google.com with SMTP id n41so1536270qco.7 for ; Fri, 08 Feb 2013 11:36:51 -0800 (PST) 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=wjU6Gt+deJiH8nHiAJX8NRdiC5XGT1fWi0f+2PJmrqE=; b=nwla+ylgNk6V3z42YF6zkqu9r2ePTkZA9xmqfd0LmNsNkJCnL/BfkcEaPL8dMqWL50 UIt/S/Sms/VTlRiouISpJRHANXieqogf+vseaY5Bs2CYV0zcVWHcHXUBmSQq9sAy8Y5V 4z0/p1KLSaNMs0+g8RUsIUeU1Rl2vbUT6/eHGN3veC24huNztrFDQEnFFQAzKUOjIs8g DmAkYT+x3ck0GGuDk9i9UK4RzLSf4yClSIetVv4hz1bp2Pcf3iSWueQ40KS73IsQFwbD SJRish7/RXv2ta3yjs+BZ8a7246E3Oe+JRmH2X3raMACH1dY4Qc/mMWORIWRsxY/D6vB rqfg== MIME-Version: 1.0 X-Received: by 10.229.195.230 with SMTP id ed38mr565920qcb.22.1360352211700; Fri, 08 Feb 2013 11:36:51 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.49.104.139 with HTTP; Fri, 8 Feb 2013 11:36:51 -0800 (PST) In-Reply-To: <015b01ce0632$257ddca0$707995e0$@packetizer.com> References: <00c101ce057d$aa4d3300$fee79900$@packetizer.com> <64CAA751B008551D9D7EDC5B@192.168.15.107> <015b01ce0632$257ddca0$707995e0$@packetizer.com> Date: Fri, 8 Feb 2013 14:36:51 -0500 X-Google-Sender-Auth: _hrJEDPO64ewl65pVThBaoDCqJU Message-ID: From: Barry Leiba To: "Paul E. Jones" Content-Type: text/plain; charset=ISO-8859-1 Cc: Chris Newman , media-types@iana.org, "webfinger@ietf.org" Subject: Re: [webfinger] [media-types] Media type application/jrd+json 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, 08 Feb 2013 19:36:52 -0000 >> Optional parameters: None > > Per RFC 6838, I must put "N/A", not "none". OK. >> In particular, because RFC 4627 already defines the character encoding >> for JSON, no "charset" parameter is permitted. > > Do we want to say that the parameter is not permitted or just say that it is > not necessary? My web server might make an attempt to add a charset > parameter in the Content-Type if I don't explicitly insert one. I've not > tested that, but I have seen odd behavior like that before, so I get in the > habit of being explicit about it. Well, RFC 6657 explains the problems with conflicting charset information. Even though this isn't a "text/*" media type, the issues apply here as well, as, I think, do the conclusions: that media type registrations should either (quoting from 6657 here) a. specify that the "charset" parameter is not used for the defined subtype, because the charset information is transported inside the payload (such as in "text/xml"), or b. require explicit unconditional inclusion of the "charset" parameter, eliminating the need for a default value. I'm suggesting (a), but I'm also happy if you think it's safer to do (b), as long as you make it clear that the only acceptable values are UTF-8, UTF-16, and UTF-32, and that the one specified must match the encoding used in the content. b From derhoermi@gmx.net Fri Feb 8 13:52: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 D515221F8C05 for ; Fri, 8 Feb 2013 13:52:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.699 X-Spam-Level: X-Spam-Status: No, score=-4.699 tagged_above=-999 required=5 tests=[AWL=-2.700, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5NqJW-yhJmT for ; Fri, 8 Feb 2013 13:52:03 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 1EDAE21F8C07 for ; Fri, 8 Feb 2013 13:52:03 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.27]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MBYz2-1UC9LA0p5a-00AYse for ; Fri, 08 Feb 2013 22:52:02 +0100 Received: (qmail invoked by alias); 08 Feb 2013 21:52:01 -0000 Received: from pD9539135.dip.t-dialin.net (EHLO netb.Speedport_W_700V) [217.83.145.53] by mail.gmx.net (mp027) with SMTP; 08 Feb 2013 22:52:01 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1/+GZthFI7+obADivJyn/XZPIXFmaHtcqNE7Ox11z 5QHHg5Tz8nIlO1 From: Bjoern Hoehrmann To: "Paul E. Jones" Date: Fri, 08 Feb 2013 22:52:02 +0100 Message-ID: References: <00c101ce057d$aa4d3300$fee79900$@packetizer.com> <015201ce0630$86fe9070$94fbb150$@packetizer.com> In-Reply-To: <015201ce0630$86fe9070$94fbb150$@packetizer.com> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: webfinger@ietf.org, 'Barry Leiba' , media-types@iana.org Subject: Re: [webfinger] [media-types] Media type application/jrd+json 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, 08 Feb 2013 21:52:05 -0000 * Paul E. Jones wrote: >> >Fragment identifier considerations: N/A >> >> As above, given RFC 6839 it's not clear what this means. > >I have no clue what to put here, honestly. Can you suggest text or point me >to text I can borrow? I'm not aware of a spec that defines how to use the >fragment syntax to dereference part of a JSON object, though some attempts >have been made to define that. Is there something we should use? We >certainly can define that within this document, as that is a whole problem >unto itself. You could say something like "Same as for application/json" or "As per RFC 6839" or say fragment identifier semantics are not defined for now because the WebFinger community is still discussing this and it is un- clear whether following the general +json conventions is suitable for this type, as far as I am concerned. You just can't say nothing while RFC 6839 says you SHOULD do something specific. >> > File extension(s): jrd+json >> >> Are you sure about having a `+` in file extensions? > >I have absolutely no preference, though this extension would make it easier >for some using the Apache web server. We could just call it "jrd". I'm OK >with flipping a coin on this one. A possible problem is that file extensions often end up in regular ex- pressions of some form, or in query strings in URLs, where the `+` may be interpreted in a surprising manner, but I do not really care either. >I have modified the template per your advice, though we might need to adjust >it further based on the answers to the above. I put the updated template >below. Looks better, thanks. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From Michael.Jones@microsoft.com Fri Feb 8 13:55:19 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 6FB9921F8BB7 for ; Fri, 8 Feb 2013 13:55:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6mfHSraZpq2 for ; Fri, 8 Feb 2013 13:55:18 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.27]) by ietfa.amsl.com (Postfix) with ESMTP id BDE5621F89FC for ; Fri, 8 Feb 2013 13:55:18 -0800 (PST) Received: from BY2FFO11FD014.protection.gbl (10.1.15.200) by BY2FFO11HUB019.protection.gbl (10.1.14.178) with Microsoft SMTP Server (TLS) id 15.0.620.12; Fri, 8 Feb 2013 21:55:16 +0000 Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD014.mail.protection.outlook.com (10.1.14.76) with Microsoft SMTP Server (TLS) id 15.0.609.9 via Frontend Transport; Fri, 8 Feb 2013 21:55:16 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.132]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0318.003; Fri, 8 Feb 2013 21:54:50 +0000 From: Mike Jones To: Bjoern Hoehrmann , "Paul E. Jones" Thread-Topic: [webfinger] [media-types] Media type application/jrd+json Thread-Index: AQHOBjA98omDNiCrwE67b/ziBYEdDZhwVKsAgAAsAgCAAACXUA== Date: Fri, 8 Feb 2013 21:54:49 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394367421591@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <00c101ce057d$aa4d3300$fee79900$@packetizer.com> <015201ce0630$86fe9070$94fbb150$@packetizer.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.73] 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)(13464002)(377454001)(24454001)(189002)(199002)(51856001)(16601075001)(77982001)(76482001)(47736001)(4396001)(50986001)(47976001)(50466001)(59766001)(49866001)(5343655001)(33656001)(79102001)(55846006)(23756002)(46102001)(74662001)(44976002)(31966008)(47446002)(15202345001)(74502001)(54356001)(16406001)(66066001)(80022001)(53806001)(20776003)(54316002)(63696002)(47776003)(56776001)(56816002)(65816001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB019; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0751474A44 Cc: "webfinger@ietf.org" , 'Barry Leiba' , "media-types@iana.org" Subject: Re: [webfinger] [media-types] Media type application/jrd+json 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, 08 Feb 2013 21:55:19 -0000 If a file extension is going to be defined for the media type, I believe th= at it should be "jrd". -- Mike -----Original Message----- From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] On Beh= alf Of Bjoern Hoehrmann Sent: Friday, February 08, 2013 1:52 PM To: Paul E. Jones Cc: webfinger@ietf.org; 'Barry Leiba'; media-types@iana.org Subject: Re: [webfinger] [media-types] Media type application/jrd+json * Paul E. Jones wrote: >> >Fragment identifier considerations: N/A >>=20 >> As above, given RFC 6839 it's not clear what this means. > >I have no clue what to put here, honestly. Can you suggest text or=20 >point me to text I can borrow? I'm not aware of a spec that defines=20 >how to use the fragment syntax to dereference part of a JSON object,=20 >though some attempts have been made to define that. Is there something=20 >we should use? We certainly can define that within this document, as=20 >that is a whole problem unto itself. You could say something like "Same as for application/json" or "As per RFC = 6839" or say fragment identifier semantics are not defined for now because = the WebFinger community is still discussing this and it is un- clear whethe= r following the general +json conventions is suitable for this type, as far= as I am concerned. You just can't say nothing while RFC 6839 says you SHOU= LD do something specific. >> > File extension(s): jrd+json >>=20 >> Are you sure about having a `+` in file extensions? > >I have absolutely no preference, though this extension would make it=20 >easier for some using the Apache web server. We could just call it=20 >"jrd". I'm OK with flipping a coin on this one. A possible problem is that file extensions often end up in regular ex- pres= sions of some form, or in query strings in URLs, where the `+` may be inter= preted in a surprising manner, but I do not really care either. >I have modified the template per your advice, though we might need to=20 >adjust it further based on the answers to the above. I put the updated=20 >template below. Looks better, thanks. -- Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 http://bjoern.hoehrma= nn.de Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 http://www.bjoernsw= orld.de 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev.d= e/ _______________________________________________ webfinger mailing list webfinger@ietf.org https://www.ietf.org/mailman/listinfo/webfinger From barryleiba@gmail.com Fri Feb 8 13:59: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 755BC21F8B73 for ; Fri, 8 Feb 2013 13:59:42 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oE8olf4UxTEW for ; Fri, 8 Feb 2013 13:59:42 -0800 (PST) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id D15B421F8B9B for ; Fri, 8 Feb 2013 13:59:41 -0800 (PST) Received: by mail-la0-f41.google.com with SMTP id fo12so4283935lab.0 for ; Fri, 08 Feb 2013 13:59:40 -0800 (PST) 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=MQewtSS7DdMSA8d+orotOXU+nzBueBFBEvoK1sdiutM=; b=O3isIUKJONlJoyd1P/bdP940d4nMNkzQndKIjueeYRMYS57C232sVpfshN5KXo4J1k i+EbyNq4xXfjwNYDrh1TaOEu2BMKQEVyI3h8fB+UZDP5Z40mC+zgQQUH9sFOwsUZ9Uzw nmgsqRgkXUJxEKI3DvNBfyCJZzcI4np5SdoaeQd8W/3sDLWpQfBMoNmsWDyNEzRhNMgc q6FNKbDRG9ixguemY5b2vTXZe/tjr2G603MPf9KVU8e+qOpuJV1X3s65qAP2FwzVINv4 hsarAJywad44V3krbrGm9OGBPjXAVdpiXnCxSAEGfbNyQE0mILoluNfcu6PgvkKYmYo5 mXNQ== MIME-Version: 1.0 X-Received: by 10.152.144.130 with SMTP id sm2mr6200059lab.49.1360360780679; Fri, 08 Feb 2013 13:59:40 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.112.47.168 with HTTP; Fri, 8 Feb 2013 13:59:40 -0800 (PST) In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367421591@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <00c101ce057d$aa4d3300$fee79900$@packetizer.com> <015201ce0630$86fe9070$94fbb150$@packetizer.com> <4E1F6AAD24975D4BA5B168042967394367421591@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Fri, 8 Feb 2013 16:59:40 -0500 X-Google-Sender-Auth: VvFSh3UOqwzigmmP1HUMa3QexcA Message-ID: From: Barry Leiba To: Mike Jones Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "Paul E. Jones" , Bjoern Hoehrmann , "media-types@iana.org" , "webfinger@ietf.org" Subject: Re: [webfinger] [media-types] Media type application/jrd+json 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, 08 Feb 2013 21:59:42 -0000 > If a file extension is going to be defined for the media type, I believe = that it should be "jrd". =D0=94=D0=B0. Barry From paulej@packetizer.com Fri Feb 8 14:00: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 231BC21F8BF6 for ; Fri, 8 Feb 2013 14:00:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id toArJXWsNql5 for ; Fri, 8 Feb 2013 14:00:25 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id CFCB221F8BF8 for ; Fri, 8 Feb 2013 14:00:24 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r18LxwXd024401 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 8 Feb 2013 16:59:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1360360799; bh=3VZd7sSA1gcEnZ3/q+JsCFDlif9XjLDePVdXeITuYrA=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=ONbD3jiuCt2TypTeEu5HFJVA+yEIZOIc1QxC2ant1NBR9wCLjbW/R8eUOwySmU6j6 mWvwQl6KsdSWAwhHSnrdX2Rt104TaMbcXosjPKzxy+WZpSHG8ZXV9H+aX8/6ianC79 +FtzAF9YYJ9Sy83xnlpRKPUZo57QIL19YRfDXGwY= From: "Paul E. Jones" To: "'Barry Leiba'" References: <00c101ce057d$aa4d3300$fee79900$@packetizer.com> <64CAA751B008551D9D7EDC5B@192.168.15.107> <015b01ce0632$257ddca0$707995e0$@packetizer.com> In-Reply-To: Date: Fri, 8 Feb 2013 17:00:05 -0500 Message-ID: <01da01ce0647$a70cc640$f52652c0$@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: AQFrjVDtUGtO0BjHiisI9WYoTvSPaADexDJ4AlyhwCMCM09v/gIfWwAemPkD5tA= Content-Language: en-us Cc: 'Chris Newman' , media-types@iana.org, webfinger@ietf.org Subject: Re: [webfinger] [media-types] Media type application/jrd+json 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, 08 Feb 2013 22:00:29 -0000 "not used" sounds reasonable. Using your language (plus "not used")... In particular, because RFC 4627 already defines the character encoding for JSON, no "charset" parameter is used. Paul > -----Original Message----- > From: barryleiba@gmail.com [mailto:barryleiba@gmail.com] On Behalf Of > Barry Leiba > Sent: Friday, February 08, 2013 2:37 PM > To: Paul E. Jones > Cc: Chris Newman; media-types@iana.org; webfinger@ietf.org > Subject: Re: [media-types] Media type application/jrd+json > > >> Optional parameters: None > > > > Per RFC 6838, I must put "N/A", not "none". > > OK. > > >> In particular, because RFC 4627 already defines the character > encoding > >> for JSON, no "charset" parameter is permitted. > > > > Do we want to say that the parameter is not permitted or just say that > > it is not necessary? My web server might make an attempt to add a > > charset parameter in the Content-Type if I don't explicitly insert > > one. I've not tested that, but I have seen odd behavior like that > > before, so I get in the habit of being explicit about it. > > Well, RFC 6657 explains the problems with conflicting charset > information. Even though this isn't a "text/*" media type, the issues > apply here as well, as, I think, do the conclusions: that media type > registrations should either (quoting from 6657 here) > > a. specify that the "charset" parameter is not used for the defined > subtype, because the charset information is transported inside > the payload (such as in "text/xml"), or > > b. require explicit unconditional inclusion of the "charset" > parameter, eliminating the need for a default value. > > I'm suggesting (a), but I'm also happy if you think it's safer to do (b), > as long as you make it clear that the only acceptable values are UTF-8, > UTF-16, and UTF-32, and that the one specified must match the encoding > used in the content. > > b From paulej@packetizer.com Fri Feb 8 14:27: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 54B9B21F87FA for ; Fri, 8 Feb 2013 14:27:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgpK-wdMk30n for ; Fri, 8 Feb 2013 14:27:10 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 1460721F8815 for ; Fri, 8 Feb 2013 14:27:10 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r18MQfWm026132 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 8 Feb 2013 17:26:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1360362401; bh=A8tSVgqy8QG8kNYeNIICAjn2jPO/Yh47btprB7AM0Dw=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=IY4sk6SuP9SMPFTnEPAYYwSypgPY8ornMIbdyldmPFBCA0lWgw8Ej6CR0OMC6+h5H aGwQsKiEv0q+CA3mlxKijdD2g3Iq9+2AmzkVtawkd+Gm++vIY6wfMDaD+tqD06qIC7 UbWZX6a9rbDZAidJytctq7/stpiyd9JKUCLqdoRw= From: "Paul E. Jones" To: "'Bjoern Hoehrmann'" References: <00c101ce057d$aa4d3300$fee79900$@packetizer.com> <015201ce0630$86fe9070$94fbb150$@packetizer.com> In-Reply-To: Date: Fri, 8 Feb 2013 17:26:47 -0500 Message-ID: <021601ce064b$6242c560$26c85020$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFrjVDtUGtO0BjHiisI9WYoTvSPaAGmeMp9ArWpI0sDArXCGZj6hGBg Content-Language: en-us Cc: webfinger@ietf.org, 'Barry Leiba' , media-types@iana.org Subject: Re: [webfinger] [media-types] Media type application/jrd+json 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, 08 Feb 2013 22:27:10 -0000 Bj=F6rn, > >I have no clue what to put here, honestly. Can you suggest text or > >point me to text I can borrow? I'm not aware of a spec that defines > >how to use the fragment syntax to dereference part of a JSON object, > >though some attempts have been made to define that. Is there = something > >we should use? We certainly can define that within this document, as > >that is a whole problem unto itself. >=20 > You could say something like "Same as for application/json" or "As per > RFC 6839" or say fragment identifier semantics are not defined for now > because the WebFinger community is still discussing this and it is un- > clear whether following the general +json conventions is suitable for > this type, as far as I am concerned. You just can't say nothing while > RFC 6839 says you SHOULD do something specific. We're not inventing anything new here: this format is just a JSON = object. So, perhaps the best solution is to just borrow words from RFC 6839: The syntax and semantics of fragment identifiers SHOULD be as = specified for "application/json". (At publication of this document, there is = no fragment identification syntax defined for "application/json".) That OK? =20 > >> > File extension(s): jrd+json > >> > >> Are you sure about having a `+` in file extensions? > > > >I have absolutely no preference, though this extension would make it > >easier for some using the Apache web server. We could just call it > >"jrd". I'm OK with flipping a coin on this one. >=20 > A possible problem is that file extensions often end up in regular ex- > pressions of some form, or in query strings in URLs, where the `+` may > be interpreted in a surprising manner, but I do not really care = either. I'll ask the WF group separately on this and see if I can get closure. Thanks! Paul From paulej@packetizer.com Fri Feb 8 14:29: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 3BB9221F8B6E for ; Fri, 8 Feb 2013 14:29:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.231 X-Spam-Level: X-Spam-Status: No, score=-2.231 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4kQggpqDWF5o for ; Fri, 8 Feb 2013 14:29:24 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 64C1121F87FA for ; Fri, 8 Feb 2013 14:29:24 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r18MTNTE026342 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 8 Feb 2013 17:29:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1360362563; bh=98AJoRYNq0tHagyOVAvyDxXqhZewlp4qQcwu1DHenx0=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; b=IAoqv+Hexu73Sun4oHuh1100Sva9PAws0xm6AMcxDcvLdBPwWEQHSX1b0O3zqxp60 c74mHbzp8a4v4KlnOcyfn2s64HvSku8a51OR7JjjdXa+Jcfa9JetBooN0Lt9MOLRnG gFndbSq/D+ol/6zDl6JxXNqYfvayZE7rWq0xK/W0= From: "Paul E. Jones" To: Date: Fri, 8 Feb 2013 17:29:29 -0500 Message-ID: <021801ce064b$c2cef520$486cdf60$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0219_01CE0621.D9F93B40" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4GS8GfU+ud2X/6QImd0d2hAOw5zQ== Content-Language: en-us Subject: [webfinger] Webfinger JRD file extenion 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, 08 Feb 2013 22:29:25 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0219_01CE0621.D9F93B40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Folks, =20 For the jrd+json media type, we need an extension. I specified = =93jrd+json=94, but you might have seen Bj=F6rn=92s comment that this might not be ideal = if used with regular expressions. =20 I have no preference. =20 Shall we lay claim to =93.jrd=94? Any known conflicts? =20 Paul =20 ------=_NextPart_000_0219_01CE0621.D9F93B40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Folks,

 

For the = jrd+json media type, we need an extension.=A0 I specified = “jrd+json”, but you might have seen Bj=F6rn’s comment = that this might not be ideal if used with regular = expressions.

 

I have no preference.

 

Shall we lay = claim to “.jrd”?=A0 Any known conflicts?

 

Paul

 

------=_NextPart_000_0219_01CE0621.D9F93B40-- From paulej@packetizer.com Fri Feb 8 14:31:06 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 E15F821F87FA for ; Fri, 8 Feb 2013 14:31:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVfHa2F5hMqo for ; Fri, 8 Feb 2013 14:31:06 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 96E5821F88CA for ; Fri, 8 Feb 2013 14:31:06 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r18MUeMX026428 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 8 Feb 2013 17:30:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1360362641; bh=zQPJMQ4V70MdjdQ0Ec00lidG5iv31w8RZfZL7/bjCJA=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=sGizTWqby/XiW2zojQ1rRb1cmdsbeWymkmng96oCgA/2zqIz5fE1xNaYgjL0fU/lR topmRCtYMuZgR2mtuiKNy8vjzj3G6CmnMsVBeAaCcVx3+zX+0bXJF+EPwCQvXBTevt DGeZskoc6MUHgDdAo9XLdssj4oaT12yEu6s8Xdzw= From: "Paul E. Jones" To: "'Mike Jones'" , "'Bjoern Hoehrmann'" References: <00c101ce057d$aa4d3300$fee79900$@packetizer.com> <015201ce0630$86fe9070$94fbb150$@packetizer.com> <4E1F6AAD24975D4BA5B168042967394367421591@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367421591@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Fri, 8 Feb 2013 17:30:47 -0500 Message-ID: <022501ce064b$f103b930$d30b2b90$@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: AQFrjVDtUGtO0BjHiisI9WYoTvSPaAGmeMp9ArWpI0sDArXCGQIN4EOlmOoXXSA= Content-Language: en-us Cc: webfinger@ietf.org, 'Barry Leiba' , media-types@iana.org Subject: Re: [webfinger] [media-types] Media type application/jrd+json 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, 08 Feb 2013 22:31:07 -0000 Thanks, Mike. I didn't see your reply before sending the other email on this topic. Paul > -----Original Message----- > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > Sent: Friday, February 08, 2013 4:55 PM > To: Bjoern Hoehrmann; Paul E. Jones > Cc: webfinger@ietf.org; 'Barry Leiba'; media-types@iana.org > Subject: RE: [webfinger] [media-types] Media type application/jrd+json > > If a file extension is going to be defined for the media type, I believe > that it should be "jrd". > > -- Mike > From tbray@textuality.com Fri Feb 8 14:32: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 4EA8C21F87F6 for ; Fri, 8 Feb 2013 14:32:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[AWL=-1.175, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZ+XKnG69O80 for ; Fri, 8 Feb 2013 14:32:32 -0800 (PST) Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) by ietfa.amsl.com (Postfix) with ESMTP id 9398321F841E for ; Fri, 8 Feb 2013 14:32:32 -0800 (PST) Received: by mail-pa0-f53.google.com with SMTP id bg4so2274957pad.12 for ; Fri, 08 Feb 2013 14:32:32 -0800 (PST) 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=zyYFYBFO64PwXcFuNJZConyUqDhZeEkBAHuCh1jW+ow=; b=fH/GBG9bhFB6VDiuP4NFaQV0WlzA7FWJuH1X/cOUut3qX0H+lDYOsae4F91ADyKXbL XW8v4425VNqFrs6/XXTYawtyfQfwtduEZfplkaplspaXmNy+38NmjbB9OBR0tMPccgs6 MTp5V/q4+3D+IuYVmQY4S9PqdEQgkMr85qpz8oNalwZsubtSr318N/gwUJEQeCE9P/s4 3VjsSyG1tTBqqKN0tPegE8lwAUehw/RqY4ncrPZVBoamH56LoswVk1qfivwVPcuNrWrX pfKhnxucdyp8XqNKW+2qdWqJPXMj8LEf5T/YAb6jPYwrIupUfQi/Dtgx1+D68ErDKlbv 4Xtw== MIME-Version: 1.0 X-Received: by 10.66.88.164 with SMTP id bh4mr21585808pab.41.1360362751955; Fri, 08 Feb 2013 14:32:31 -0800 (PST) Received: by 10.66.148.165 with HTTP; Fri, 8 Feb 2013 14:32:31 -0800 (PST) X-Originating-IP: [96.49.72.110] In-Reply-To: <021801ce064b$c2cef520$486cdf60$@packetizer.com> References: <021801ce064b$c2cef520$486cdf60$@packetizer.com> Date: Fri, 8 Feb 2013 14:32:31 -0800 Message-ID: From: Tim Bray To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=f46d042dfcd198935804d53e22b9 X-Gm-Message-State: ALoCoQlKLYj2u5coa07gaC0dxxl+0AywFgQIs+VUh934jcg4AZBrHKMIJBiGyfLZFpCuitAXgu9k Cc: "webfinger@ietf.org" Subject: Re: [webfinger] Webfinger JRD file extenion 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, 08 Feb 2013 22:32:33 -0000 --f46d042dfcd198935804d53e22b9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Looks like the land is there to be grapped, per http://en.wikipedia.org/wiki/Alphabetical_list_of_file_formats_(F-L)#J On Fri, Feb 8, 2013 at 2:29 PM, Paul E. Jones wrote= : > Folks,**** > > ** ** > > For the jrd+json media type, we need an extension. I specified > =93jrd+json=94, but you might have seen Bj=F6rn=92s comment that this mig= ht not be > ideal if used with regular expressions.**** > > ** ** > > I have no preference.**** > > ** ** > > Shall we lay claim to =93.jrd=94? Any known conflicts?**** > > ** ** > > Paul**** > > ** ** > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > > --f46d042dfcd198935804d53e22b9 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Looks like the land is there to be grapped, per ht= tp://en.wikipedia.org/wiki/Alphabetical_list_of_file_formats_(F-L)#J


On Fri,= Feb 8, 2013 at 2:29 PM, Paul E. Jones <paulej@packetizer.com><= /span> wrote:

Folks,

=A0

For the jrd+json media type, we need an extension.= =A0 I specified =93jrd+json=94, but you might have seen Bj=F6rn=92s comment= that this might not be ideal if used with regular expressions.

=A0

I have no preference.=

=A0

= Shall we lay claim to =93.jrd=94?=A0 Any known conflicts?

=A0

Paul

=A0


_______________= ________________________________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger


--f46d042dfcd198935804d53e22b9-- From paulej@packetizer.com Fri Feb 8 14:42: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 EA9DB21F8BDB for ; Fri, 8 Feb 2013 14:42:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.226 X-Spam-Level: X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=-0.228, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6NW88YMD27M8 for ; Fri, 8 Feb 2013 14:42:11 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id C3FD521F8BD4 for ; Fri, 8 Feb 2013 14:42:10 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r18Mg913027290 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 8 Feb 2013 17:42:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1360363330; bh=uWKcU1Vb9hoG9Y3dfEmE28oqoluDfZ5Rm+99jggYQJc=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=ej1j8WDo3pkF1y4Gi0SXCDEErcZzV96xIiikOAlWTFXyohnjjeTgljWCPZGbw6Y5F 9Is+ogLpI4kzuPxABh8d9Jha5AWlAjJ88ggibxWf7psDCPNlGZ9jTZt3QOzt/nhGO3 NeJ83qSRcHLBLCxribkZaJrr12NSBJRxnnX6fqCs= From: "Paul E. Jones" To: "'Tim Bray'" References: <021801ce064b$c2cef520$486cdf60$@packetizer.com> In-Reply-To: Date: Fri, 8 Feb 2013 17:42:16 -0500 Message-ID: <023901ce064d$8ba46ba0$a2ed42e0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_023A_01CE0623.A2CEFFE0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQCTn/HxOzsSykOXBKg80kYNVMl1RgMNZ/D3mszv5lA= Content-Language: en-us Cc: webfinger@ietf.org Subject: Re: [webfinger] Webfinger JRD file extenion 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, 08 Feb 2013 22:42:12 -0000 This is a multipart message in MIME format. ------=_NextPart_000_023A_01CE0623.A2CEFFE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable OK.. =93jrd=94 it is. =20 Paul =20 From: Tim Bray [mailto:tbray@textuality.com]=20 Sent: Friday, February 08, 2013 5:33 PM To: Paul E. Jones Cc: webfinger@ietf.org Subject: Re: [webfinger] Webfinger JRD file extenion =20 Looks like the land is there to be grapped, per http://en.wikipedia.org/wiki/Alphabetical_list_of_file_formats_(F-L)#J=20 =20 On Fri, Feb 8, 2013 at 2:29 PM, Paul E. Jones = wrote: Folks, =20 For the jrd+json media type, we need an extension. I specified = =93jrd+json=94, but you might have seen Bj=F6rn=92s comment that this might not be ideal = if used with regular expressions. =20 I have no preference. =20 Shall we lay claim to =93.jrd=94? Any known conflicts? =20 Paul =20 _______________________________________________ webfinger mailing list webfinger@ietf.org https://www.ietf.org/mailman/listinfo/webfinger =20 ------=_NextPart_000_023A_01CE0623.A2CEFFE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

OK.. “jrd” it is.

 

Paul

 

From:= = Tim Bray [mailto:tbray@textuality.com]
Sent: Friday, February = 08, 2013 5:33 PM
To: Paul E. Jones
Cc: = webfinger@ietf.org
Subject: Re: [webfinger] Webfinger JRD file = extenion

 

Looks = like the land is there to be grapped, per http://en.wikipedia.org/wiki/Alphabetical_list_of_file_formats_(F-= L)#J

 

On Fri, Feb 8, 2013 at 2:29 PM, Paul E. Jones <paulej@packetizer.com> = wrote:

Folks,<= /o:p>

 <= /o:p>

For the = jrd+json media type, we need an extension.  I specified = “jrd+json”, but you might have seen Bj=F6rn’s comment = that this might not be ideal if used with regular = expressions.

 <= /o:p>

I have no = preference.

 <= /o:p>

Shall we = lay claim to “.jrd”?  Any known = conflicts?

 

Paul

 


______________________________________= _________
webfinger mailing list
webfinger@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger

 

------=_NextPart_000_023A_01CE0623.A2CEFFE0-- From paulej@packetizer.com Fri Feb 8 20:23: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 737A621F8BED for ; Fri, 8 Feb 2013 20:23:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6dKdH0IuTOZ for ; Fri, 8 Feb 2013 20:23:17 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 9729921F8BB7 for ; Fri, 8 Feb 2013 20:23:17 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r194NFSW011874 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 8 Feb 2013 23:23:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1360383796; bh=3wYTt/7nicbpekLAWRnE9Q2WmplxmJfB9yHqLFhcpW0=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=XLfaRNHCB326PDAsyqVl3J7DYjzyhaUhMbCUCNHS752OgEKGuXSohXbzh0XPUVK6C Af75ZXq9oWcXe6QZjr2QPQfk0K6v3vpQhY2Hc7FjifmFrJyloqN/YU8j4C0sj3yy4p 8Cu/5dBw9UA9b/7m4XnLzwXwYl8cOamq73kWBMks= From: "Paul E. Jones" To: References: <20130209033118.8995.1805.idtracker@ietfa.amsl.com> In-Reply-To: <20130209033118.8995.1805.idtracker@ietfa.amsl.com> Date: Fri, 8 Feb 2013 23:23:21 -0500 Message-ID: <028d01ce067d$32872780$97957680$@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: AQK3KbRB5uUm0GlpDFalypD3Y1ldzJaepnoA Content-Language: en-us Cc: webfinger@googlegroups.com Subject: [webfinger] FW: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-10.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: Sat, 09 Feb 2013 04:23:18 -0000 Folks, I tried to accurately reflect all of the suggested editorial and technical changes. The only "technical" changes were: * Removal of the "expires" member from the JRD object * Introduction of the application/jrd+json media type Please have a look over this version and let me know if you find any issues. If there are none, we may be set to move this along. Paul > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: Friday, February 08, 2013 10:31 PM > To: i-d-announce@ietf.org > Cc: apps-discuss@ietf.org > Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-10.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Applications Area Working Group > Working Group of the IETF. > > Title : WebFinger > Author(s) : Paul E. Jones > Gonzalo Salgueiro > Joseph Smarr > Filename : draft-ietf-appsawg-webfinger-10.txt > Pages : 22 > Date : 2013-02-08 > > Abstract: > This specification defines the WebFinger protocol, which can be used > to discover information about people or other entities on the > Internet using standard HTTP methods. WebFinger discovers > information for a URI that might not be usable as a locator > otherwise, such as account or email URIs. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-10 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-webfinger-10 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From stpeter@stpeter.im Fri Feb 8 20:27: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 2FCC121F8C75 for ; Fri, 8 Feb 2013 20:27:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PIcvJrauOV4i for ; Fri, 8 Feb 2013 20:27:28 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4F80721F8BEF for ; Fri, 8 Feb 2013 20:27:24 -0800 (PST) Received: from [192.168.1.2] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E9E3B4004E for ; Fri, 8 Feb 2013 21:34:13 -0700 (MST) Message-ID: <5115D02B.4040205@stpeter.im> Date: Fri, 08 Feb 2013 21:27:23 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: webfinger@ietf.org References: <20130209033118.8995.1805.idtracker@ietfa.amsl.com> <028d01ce067d$32872780$97957680$@packetizer.com> In-Reply-To: <028d01ce067d$32872780$97957680$@packetizer.com> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [webfinger] FW: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-10.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: Sat, 09 Feb 2013 04:27:29 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ship it! On 2/8/13 9:23 PM, Paul E. Jones wrote: > Folks, > > I tried to accurately reflect all of the suggested editorial and > technical changes. > > The only "technical" changes were: * Removal of the "expires" > member from the JRD object * Introduction of the > application/jrd+json media type > > Please have a look over this version and let me know if you find > any issues. If there are none, we may be set to move this along. > > Paul > >> -----Original Message----- From: apps-discuss-bounces@ietf.org >> [mailto:apps-discuss- bounces@ietf.org] On Behalf Of >> internet-drafts@ietf.org Sent: Friday, February 08, 2013 10:31 >> PM To: i-d-announce@ietf.org Cc: apps-discuss@ietf.org Subject: >> [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-10.txt >> >> >> A New Internet-Draft is available from the on-line >> Internet-Drafts directories. This draft is a work item of the >> Applications Area Working Group Working Group of the IETF. >> >> Title : WebFinger Author(s) : Paul E. Jones >> Gonzalo Salgueiro Joseph Smarr Filename : >> draft-ietf-appsawg-webfinger-10.txt Pages : 22 Date >> : 2013-02-08 >> >> Abstract: This specification defines the WebFinger protocol, >> which can be used to discover information about people or other >> entities on the Internet using standard HTTP methods. WebFinger >> discovers information for a URI that might not be usable as a >> locator otherwise, such as account or email URIs. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-10 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-webfinger-10 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ apps-discuss >> mailing list apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss > > _______________________________________________ webfinger mailing > list webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRFdAqAAoJEOoGpJErxa2pfIMP/3RazeMnc0lCapeRjZ0GSL/3 rpgXFBtpnIHlLNm8U45z9lrzn+z4M1sJwiUTUsWFMQWKNp/+EHgoimdvvwtUA+Rj v+FWYX03BbtNtxedfaib3/6Y+WZ6Pi8EHZ7E/MtsFauUE2WYZM2HX/aCF8VUPKBO V3WDOPApblbfYwgp8dRWoeBOV6+ANbzpEieMhX1Rq1RPFNMtn6tSIJQNrbMUeqil tyuBTUHllaUm4Y9F15EvEgDpbcwuTKjavUQKgd6bMVRy8lLytevGVnBJlJIeHGRc CGja4q/UeST7/GxwYjwRngWP4HC/EEt1B7VmFF/akA8BThrlC4y6LobxzK6JN/32 n7AlVnip1UW1rTfStV4jE1cgL8akWN1UH5kZXhJYPOby79chtqxFTCapFBfiBhDK lhqUjcy9eaTxTyprRlICA+3TDPOHcET+drvN5EDoT9i1S0o1wKbukbL+KuBtrCUL Pa9KTNCtUZH5VQP8VAIh33dE0Fk+/JQfTCufXRlGyIE3A/vXgD/WvdkjWzra6kqL fHK7eKy/0BoDYVdakynAWZyQVkArBsMZLvXKQxj1841OZ1FikO6O93FKNEdUw4Hv Wlp+taCPfe5+w41g3YIlbRelD7RPwpBMvI3566++KxCdqJHauyeTVKMO4LenwG1u MlpTejMNM9IVFRG5qxFv =ZNm4 -----END PGP SIGNATURE----- From gsalguei@cisco.com Fri Feb 8 20:28: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 3047E21F8CB4 for ; Fri, 8 Feb 2013 20:28:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.493 X-Spam-Level: X-Spam-Status: No, score=-10.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfbplEdUBn+f for ; Fri, 8 Feb 2013 20:28:42 -0800 (PST) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 7A21321F8CB2 for ; Fri, 8 Feb 2013 20:28:42 -0800 (PST) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r194SfxN001437 for ; Fri, 8 Feb 2013 23:28:42 -0500 (EST) Received: from rtp-gsalguei-8918.cisco.com (rtp-gsalguei-8918.cisco.com [10.116.132.57]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r194SfPg005855; Fri, 8 Feb 2013 23:28:41 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Gonzalo Salgueiro In-Reply-To: <5115D02B.4040205@stpeter.im> Date: Fri, 8 Feb 2013 23:28:40 -0500 Content-Transfer-Encoding: 7bit Message-Id: <6F96D86F-04DB-4D29-9F4A-37E2A1CCEFEF@cisco.com> References: <20130209033118.8995.1805.idtracker@ietfa.amsl.com> <028d01ce067d$32872780$97957680$@packetizer.com> <5115D02B.4040205@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1499) Cc: webfinger@ietf.org Subject: Re: [webfinger] [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-10.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: Sat, 09 Feb 2013 04:28:43 -0000 Amen!! --G On Feb 8, 2013, at 11:27 PM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Ship it! > > On 2/8/13 9:23 PM, Paul E. Jones wrote: >> Folks, >> >> I tried to accurately reflect all of the suggested editorial and >> technical changes. >> >> The only "technical" changes were: * Removal of the "expires" >> member from the JRD object * Introduction of the >> application/jrd+json media type >> >> Please have a look over this version and let me know if you find >> any issues. If there are none, we may be set to move this along. >> >> Paul >> >>> -----Original Message----- From: apps-discuss-bounces@ietf.org >>> [mailto:apps-discuss- bounces@ietf.org] On Behalf Of >>> internet-drafts@ietf.org Sent: Friday, February 08, 2013 10:31 >>> PM To: i-d-announce@ietf.org Cc: apps-discuss@ietf.org Subject: >>> [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-10.txt >>> >>> >>> A New Internet-Draft is available from the on-line >>> Internet-Drafts directories. This draft is a work item of the >>> Applications Area Working Group Working Group of the IETF. >>> >>> Title : WebFinger Author(s) : Paul E. Jones >>> Gonzalo Salgueiro Joseph Smarr Filename : >>> draft-ietf-appsawg-webfinger-10.txt Pages : 22 Date >>> : 2013-02-08 >>> >>> Abstract: This specification defines the WebFinger protocol, >>> which can be used to discover information about people or other >>> entities on the Internet using standard HTTP methods. WebFinger >>> discovers information for a URI that might not be usable as a >>> locator otherwise, such as account or email URIs. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-10 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-webfinger-10 >>> >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ apps-discuss >>> mailing list apps-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/apps-discuss >> >> _______________________________________________ webfinger mailing >> list webfinger@ietf.org >> https://www.ietf.org/mailman/listinfo/webfinger >> > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJRFdAqAAoJEOoGpJErxa2pfIMP/3RazeMnc0lCapeRjZ0GSL/3 > rpgXFBtpnIHlLNm8U45z9lrzn+z4M1sJwiUTUsWFMQWKNp/+EHgoimdvvwtUA+Rj > v+FWYX03BbtNtxedfaib3/6Y+WZ6Pi8EHZ7E/MtsFauUE2WYZM2HX/aCF8VUPKBO > V3WDOPApblbfYwgp8dRWoeBOV6+ANbzpEieMhX1Rq1RPFNMtn6tSIJQNrbMUeqil > tyuBTUHllaUm4Y9F15EvEgDpbcwuTKjavUQKgd6bMVRy8lLytevGVnBJlJIeHGRc > CGja4q/UeST7/GxwYjwRngWP4HC/EEt1B7VmFF/akA8BThrlC4y6LobxzK6JN/32 > n7AlVnip1UW1rTfStV4jE1cgL8akWN1UH5kZXhJYPOby79chtqxFTCapFBfiBhDK > lhqUjcy9eaTxTyprRlICA+3TDPOHcET+drvN5EDoT9i1S0o1wKbukbL+KuBtrCUL > Pa9KTNCtUZH5VQP8VAIh33dE0Fk+/JQfTCufXRlGyIE3A/vXgD/WvdkjWzra6kqL > fHK7eKy/0BoDYVdakynAWZyQVkArBsMZLvXKQxj1841OZ1FikO6O93FKNEdUw4Hv > Wlp+taCPfe5+w41g3YIlbRelD7RPwpBMvI3566++KxCdqJHauyeTVKMO4LenwG1u > MlpTejMNM9IVFRG5qxFv > =ZNm4 > -----END PGP SIGNATURE----- > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger > From Michael.Jones@microsoft.com Fri Feb 8 21:12:15 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 0CDCB21F883F for ; Fri, 8 Feb 2013 21:12:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.397 X-Spam-Level: X-Spam-Status: No, score=-2.397 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QgRcn0qcY6hi for ; Fri, 8 Feb 2013 21:12:14 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.30]) by ietfa.amsl.com (Postfix) with ESMTP id 10F0421F85D7 for ; Fri, 8 Feb 2013 21:12:14 -0800 (PST) Received: from BY2FFO11FD014.protection.gbl (10.1.15.200) by BY2FFO11HUB040.protection.gbl (10.1.14.161) with Microsoft SMTP Server (TLS) id 15.0.609.9; Sat, 9 Feb 2013 05:12:10 +0000 Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD014.mail.protection.outlook.com (10.1.14.76) with Microsoft SMTP Server (TLS) id 15.0.609.9 via Frontend Transport; Sat, 9 Feb 2013 05:12:10 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.132]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0318.003; Sat, 9 Feb 2013 05:12:09 +0000 From: Mike Jones To: Peter Saint-Andre , Gonzalo Salgueiro Thread-Topic: [webfinger] [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-10.txt Thread-Index: Ac4GhAI5T+3Yb1y9Rk6lO5MVJnesdg== Date: Sat, 9 Feb 2013 05:12:09 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436742343D@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436742343DTK5EX14MBXC284r_" 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)(80022001)(74502001)(59766001)(47736001)(5343635001)(20776003)(31966008)(63696002)(44976002)(49866001)(51856001)(65816001)(74662001)(56816002)(54316002)(16406001)(50986001)(46102001)(33656001)(53806001)(77982001)(47976001)(76482001)(4396001)(56776001)(512874001)(79102001)(54356001)(47446002)(55846006); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB040; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:3; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 07521929C1 Cc: "webfinger@ietf.org" Subject: Re: [webfinger] [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-10.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: Sat, 09 Feb 2013 05:12:15 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436742343DTK5EX14MBXC284r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzENCg0KRnJvbTogR29uemFsbyBTYWxndWVpcm8NClNlbnQ6IOKAjkZlYnJ1YXJ54oCOIOKAjjji gI4sIOKAjjIwMTMg4oCOOOKAjjrigI4yOOKAjiDigI5QTQ0KVG86IFBldGVyIFNhaW50LUFuZHJl DQpDQzogd2ViZmluZ2VyQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3dlYmZpbmdlcl0gW2FwcHMt ZGlzY3Vzc10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1hcHBzYXdnLXdlYmZpbmdlci0xMC50eHQN Cg0KQW1lbiEhDQoNCi0tRw0KDQpPbiBGZWIgOCwgMjAxMywgYXQgMTE6MjcgUE0sIFBldGVyIFNh aW50LUFuZHJlIDxzdHBldGVyQHN0cGV0ZXIuaW0+IHdyb3RlOg0KDQo+IC0tLS0tQkVHSU4gUEdQ IFNJR05FRCBNRVNTQUdFLS0tLS0NCj4gSGFzaDogU0hBMQ0KPg0KPiBTaGlwIGl0IQ0KPg0KPiBP biAyLzgvMTMgOToyMyBQTSwgUGF1bCBFLiBKb25lcyB3cm90ZToNCj4+IEZvbGtzLA0KPj4NCj4+ IEkgdHJpZWQgdG8gYWNjdXJhdGVseSByZWZsZWN0IGFsbCBvZiB0aGUgc3VnZ2VzdGVkIGVkaXRv cmlhbCBhbmQNCj4+IHRlY2huaWNhbCBjaGFuZ2VzLg0KPj4NCj4+IFRoZSBvbmx5ICJ0ZWNobmlj YWwiIGNoYW5nZXMgd2VyZTogKiBSZW1vdmFsIG9mIHRoZSAiZXhwaXJlcyINCj4+IG1lbWJlciBm cm9tIHRoZSBKUkQgb2JqZWN0ICogSW50cm9kdWN0aW9uIG9mIHRoZQ0KPj4gYXBwbGljYXRpb24v anJkK2pzb24gbWVkaWEgdHlwZQ0KPj4NCj4+IFBsZWFzZSBoYXZlIGEgbG9vayBvdmVyIHRoaXMg dmVyc2lvbiBhbmQgbGV0IG1lIGtub3cgaWYgeW91IGZpbmQNCj4+IGFueSBpc3N1ZXMuIElmIHRo ZXJlIGFyZSBub25lLCB3ZSBtYXkgYmUgc2V0IHRvIG1vdmUgdGhpcyBhbG9uZy4NCj4+DQo+PiBQ YXVsDQo+Pg0KPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIEZyb206IGFwcHMtZGlzY3Vz cy1ib3VuY2VzQGlldGYub3JnDQo+Pj4gW21haWx0bzphcHBzLWRpc2N1c3MtIGJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZg0KPj4+IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBTZW50OiBG cmlkYXksIEZlYnJ1YXJ5IDA4LCAyMDEzIDEwOjMxDQo+Pj4gUE0gVG86IGktZC1hbm5vdW5jZUBp ZXRmLm9yZyBDYzogYXBwcy1kaXNjdXNzQGlldGYub3JnIFN1YmplY3Q6DQo+Pj4gW2FwcHMtZGlz Y3Vzc10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1hcHBzYXdnLXdlYmZpbmdlci0xMC50eHQNCj4+ Pg0KPj4+DQo+Pj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9u LWxpbmUNCj4+PiBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuIFRoaXMgZHJhZnQgaXMgYSB3 b3JrIGl0ZW0gb2YgdGhlDQo+Pj4gQXBwbGljYXRpb25zIEFyZWEgV29ya2luZyBHcm91cCBXb3Jr aW5nIEdyb3VwIG9mIHRoZSBJRVRGLg0KPj4+DQo+Pj4gVGl0bGUgICAgICAgICAgIDogV2ViRmlu Z2VyIEF1dGhvcihzKSAgICAgICA6IFBhdWwgRS4gSm9uZXMNCj4+PiBHb256YWxvIFNhbGd1ZWly byBKb3NlcGggU21hcnIgRmlsZW5hbWUgICAgICAgIDoNCj4+PiBkcmFmdC1pZXRmLWFwcHNhd2ct d2ViZmluZ2VyLTEwLnR4dCBQYWdlcyAgICAgICAgICAgOiAyMiBEYXRlDQo+Pj4gOiAyMDEzLTAy LTA4DQo+Pj4NCj4+PiBBYnN0cmFjdDogVGhpcyBzcGVjaWZpY2F0aW9uIGRlZmluZXMgdGhlIFdl YkZpbmdlciBwcm90b2NvbCwNCj4+PiB3aGljaCBjYW4gYmUgdXNlZCB0byBkaXNjb3ZlciBpbmZv cm1hdGlvbiBhYm91dCBwZW9wbGUgb3Igb3RoZXINCj4+PiBlbnRpdGllcyBvbiB0aGUgSW50ZXJu ZXQgdXNpbmcgc3RhbmRhcmQgSFRUUCBtZXRob2RzLiAgV2ViRmluZ2VyDQo+Pj4gZGlzY292ZXJz IGluZm9ybWF0aW9uIGZvciBhIFVSSSB0aGF0IG1pZ2h0IG5vdCBiZSB1c2FibGUgYXMgYQ0KPj4+ IGxvY2F0b3Igb3RoZXJ3aXNlLCBzdWNoIGFzIGFjY291bnQgb3IgZW1haWwgVVJJcy4NCj4+Pg0K Pj4+DQo+Pj4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQg aXM6DQo+Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1hcHBz YXdnLXdlYmZpbmdlcg0KPj4+DQo+Pj4gVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBh dmFpbGFibGUgYXQ6DQo+Pj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1h cHBzYXdnLXdlYmZpbmdlci0xMA0KPj4+DQo+Pj4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZl cnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91 cmwyPWRyYWZ0LWlldGYtYXBwc2F3Zy13ZWJmaW5nZXItMTANCj4+Pg0KPj4+DQo+Pj4gSW50ZXJu ZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPj4+IGZ0 cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+Pj4NCj4+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBhcHBzLWRpc2N1c3MNCj4+PiBtYWls aW5nIGxpc3QgYXBwcy1kaXNjdXNzQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9hcHBzLWRpc2N1c3MNCj4+DQo+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXyB3ZWJmaW5nZXIgbWFpbGluZw0KPj4gbGlzdCB3 ZWJmaW5nZXJAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vd2ViZmluZ2VyDQo+Pg0KPg0KPiAtLS0tLUJFR0lOIFBHUCBTSUdOQVRVUkUtLS0tLQ0KPiBW ZXJzaW9uOiBHbnVQRy9NYWNHUEcyIHYyLjAuMTggKERhcndpbikNCj4gQ29tbWVudDogVXNpbmcg R251UEcgd2l0aCBUaHVuZGVyYmlyZCAtIGh0dHA6Ly93d3cuZW5pZ21haWwubmV0Lw0KPg0KPiBp UUljQkFFQkFnQUdCUUpSRmRBcUFBb0pFT29HcEpFcnhhMnBmSU1QLzNSYXplTW5jMGxDYXBlUmpa MEdTTC8zDQo+IHJwZ1hGQnRwbklIbExObThVNDV6OWxyem4rejRNMXNKd2lVVFVzV0ZNUVdLTnAv K0VIZ29pbWR2dnd0VUErUmoNCj4gditGV1lYMDNCYnROdHhlZGZhaWIzLzZZK1daNlBpOEVIWjdF L010c0ZhdVVFMldZWk0ySFgvYUNGOFZVUEtCTw0KPiBWM1dET1BBcGJsYmZZd2dwOGRSV29lQk9W NitBTmJ6cEVpZU1oWDFScTFSUEZOTXRuNnRTSUpRTnJiTVVlcWlsDQo+IHR5dUJUVUhsbGFVbTRZ OUYxNUV2RWdEcGJjd3VUS2phdlVRS2dkNmJNVlJ5OGxMeXRldkdWbkJKbEpJZUhHUmMNCj4gQ0dq YTRxL1VlU1Q3L0d4d1lqd1JuZ1dQNEhDL0VFdDFCN1ZtRkYvYWtBOEJUaHJsQzR5NkxvYnh6SzZK Ti8zMg0KPiBuN0FsVm5pcDFVVzFyVGZTdFY0akUxY2dMOGFrV04xVUg1a1pYaEpZUE9ieTc5Y2h0 cXhGVENhcEZCZmlCaERLDQo+IGxocVVqY3k5ZWFUeFR5cHJSbElDQSszVERQT0hjRVQrZHJ2TjVF RG9UOWkxUzBvMXdLYnVrYkwrS3VCdHJDVUwNCj4gUGE5S1ROQ3RVWkg1VlFQOFZBSWgzM2RFMEZr Ky9KUWZUQ3VmWFJsR3lJRTNBL3ZYZ0QvV3Zka2pXenJhNmtxTA0KPiBmSEs3ZUt5LzBCb0RZVmRh a3luQVdaeVFWa0FyQnNNWkx2WEtReGoxODQxT1oxRmlrTzZPOTNGS05FZFV3NEh2DQo+IFdscCt0 YUNQZmU1K3c0MWczWUlsYlJlbEQ3UlB3cEJNdkkzNTY2KytLeENkcUpIYXV5ZVRWS01PNExlbndH MXUNCj4gTWxwVGVqTU5NOUlWRlJHNXF4RnYNCj4gPVpObTQNCj4gLS0tLS1FTkQgUEdQIFNJR05B VFVSRS0tLS0tDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IHdlYmZpbmdlciBtYWlsaW5nIGxpc3QNCj4gd2ViZmluZ2VyQGlldGYub3JnDQo+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vd2ViZmluZ2VyDQo+DQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQp3ZWJmaW5nZXIgbWFp bGluZyBsaXN0DQp3ZWJmaW5nZXJAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vd2ViZmluZ2VyDQo= --_000_4E1F6AAD24975D4BA5B16804296739436742343DTK5EX14MBXC284r_ Content-Type: text/html; charset="utf-8" Content-ID: <18C95DDB85F82A4EB227774AFED7DCB6@microsoft.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdiBzdHlsZT0i Zm9udC1mYW1pbHk6Q2FsaWJyaSwmcXVvdDtTZWdvZSBVSSZxdW90OyxNZWlyeW8sJnF1b3Q7TWlj cm9zb2Z0IFlhSGVpIFVJJnF1b3Q7LCZxdW90O01pY3Jvc29mdCBKaGVuZ0hlaSBVSSZxdW90Oywm cXVvdDtNYWxndW4gR290aGljJnF1b3Q7LCZxdW90O0tobWVyIFVJJnF1b3Q7LCZxdW90O05pcm1h bGEgVUkmcXVvdDssVHVuZ2EsJnF1b3Q7TGFvIFVJJnF1b3Q7LEVicmltYSxzYW5zLXNlcmlmO2Zv bnQtc2l6ZToxNnB4OyI+DQo8ZGl2PiYjNDM7MTwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxk aXYgc3R5bGU9ImJvcmRlci10b3AtY29sb3I6IHJnYigyMjksIDIyOSwgMjI5KTsgYm9yZGVyLXRv cC13aWR0aDogMnB4OyBib3JkZXItdG9wLXN0eWxlOiBzb2xpZDsiPg0KPHN0cm9uZz5Gcm9tOjwv c3Ryb25nPiZuYnNwO0dvbnphbG8gU2FsZ3VlaXJvPGJyPg0KPHN0cm9uZz5TZW50Ojwvc3Ryb25n PiZuYnNwO+KAjkZlYnJ1YXJ54oCOIOKAjjjigI4sIOKAjjIwMTMg4oCOOOKAjjrigI4yOOKAjiDi gI5QTTxicj4NCjxzdHJvbmc+VG86PC9zdHJvbmc+Jm5ic3A7UGV0ZXIgU2FpbnQtQW5kcmU8YnI+ DQo8c3Ryb25nPkNDOjwvc3Ryb25nPiZuYnNwO3dlYmZpbmdlckBpZXRmLm9yZzxicj4NCjxzdHJv bmc+U3ViamVjdDo8L3N0cm9uZz4mbmJzcDtSZTogW3dlYmZpbmdlcl0gW2FwcHMtZGlzY3Vzc10g SS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1hcHBzYXdnLXdlYmZpbmdlci0xMC50eHQ8YnI+DQo8L2Rp dj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQpBbWVuISE8YnI+DQo8YnI+DQotLUc8YnI+DQo8YnI+DQpP biBGZWIgOCwgMjAxMywgYXQgMTE6MjcgUE0sIFBldGVyIFNhaW50LUFuZHJlICZsdDtzdHBldGVy QHN0cGV0ZXIuaW0mZ3Q7IHdyb3RlOjxicj4NCjxicj4NCiZndDsgLS0tLS1CRUdJTiBQR1AgU0lH TkVEIE1FU1NBR0UtLS0tLTxicj4NCiZndDsgSGFzaDogU0hBMTxicj4NCiZndDsgPGJyPg0KJmd0 OyBTaGlwIGl0ITxicj4NCiZndDsgPGJyPg0KJmd0OyBPbiAyLzgvMTMgOToyMyBQTSwgUGF1bCBF LiBKb25lcyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyBGb2xrcyw8YnI+DQomZ3Q7Jmd0OyA8YnI+DQom Z3Q7Jmd0OyBJIHRyaWVkIHRvIGFjY3VyYXRlbHkgcmVmbGVjdCBhbGwgb2YgdGhlIHN1Z2dlc3Rl ZCBlZGl0b3JpYWwgYW5kPGJyPg0KJmd0OyZndDsgdGVjaG5pY2FsIGNoYW5nZXMuPGJyPg0KJmd0 OyZndDsgPGJyPg0KJmd0OyZndDsgVGhlIG9ubHkgJnF1b3Q7dGVjaG5pY2FsJnF1b3Q7IGNoYW5n ZXMgd2VyZTogKiBSZW1vdmFsIG9mIHRoZSAmcXVvdDtleHBpcmVzJnF1b3Q7PGJyPg0KJmd0OyZn dDsgbWVtYmVyIGZyb20gdGhlIEpSRCBvYmplY3QgKiBJbnRyb2R1Y3Rpb24gb2YgdGhlPGJyPg0K Jmd0OyZndDsgYXBwbGljYXRpb24vanJkJiM0Mztqc29uIG1lZGlhIHR5cGU8YnI+DQomZ3Q7Jmd0 OyA8YnI+DQomZ3Q7Jmd0OyBQbGVhc2UgaGF2ZSBhIGxvb2sgb3ZlciB0aGlzIHZlcnNpb24gYW5k IGxldCBtZSBrbm93IGlmIHlvdSBmaW5kPGJyPg0KJmd0OyZndDsgYW55IGlzc3Vlcy4gSWYgdGhl cmUgYXJlIG5vbmUsIHdlIG1heSBiZSBzZXQgdG8gbW92ZSB0aGlzIGFsb25nLjxicj4NCiZndDsm Z3Q7IDxicj4NCiZndDsmZ3Q7IFBhdWw8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsg LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gRnJvbTogYXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0 Zi5vcmc8YnI+DQomZ3Q7Jmd0OyZndDsgW21haWx0bzphcHBzLWRpc2N1c3MtIGJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZjxicj4NCiZndDsmZ3Q7Jmd0OyBpbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmcgU2VudDogRnJpZGF5LCBGZWJydWFyeSAwOCwgMjAxMyAxMDozMTxicj4NCiZndDsmZ3Q7 Jmd0OyBQTSBUbzogaS1kLWFubm91bmNlQGlldGYub3JnIENjOiBhcHBzLWRpc2N1c3NAaWV0Zi5v cmcgU3ViamVjdDo8YnI+DQomZ3Q7Jmd0OyZndDsgW2FwcHMtZGlzY3Vzc10gSS1EIEFjdGlvbjog ZHJhZnQtaWV0Zi1hcHBzYXdnLXdlYmZpbmdlci0xMC50eHQ8YnI+DQomZ3Q7Jmd0OyZndDsgPGJy Pg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyBBIE5ldyBJbnRlcm5ldC1EcmFmdCBp cyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZTxicj4NCiZndDsmZ3Q7Jmd0OyBJbnRlcm5ldC1E cmFmdHMgZGlyZWN0b3JpZXMuIFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlPGJyPg0K Jmd0OyZndDsmZ3Q7IEFwcGxpY2F0aW9ucyBBcmVhIFdvcmtpbmcgR3JvdXAgV29ya2luZyBHcm91 cCBvZiB0aGUgSUVURi48YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7IFRpdGxl Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IDogV2ViRmluZ2VyIEF1dGhvcihzKSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyA6IFBhdWwgRS4gSm9uZXMgPGJyPg0KJmd0OyZndDsmZ3Q7IEdvbnphbG8gU2FsZ3VlaXJv IEpvc2VwaCBTbWFyciBGaWxlbmFtZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyA6PGJyPg0KJmd0OyZndDsmZ3Q7IGRyYWZ0LWlldGYtYXBwc2F3Zy13ZWJmaW5nZXIt MTAudHh0IFBhZ2VzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IDogMjIgRGF0ZTxicj4NCiZndDsmZ3Q7Jmd0OyA6IDIwMTMtMDItMDg8 YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7IEFic3RyYWN0OiBUaGlzIHNwZWNp ZmljYXRpb24gZGVmaW5lcyB0aGUgV2ViRmluZ2VyIHByb3RvY29sLDxicj4NCiZndDsmZ3Q7Jmd0 OyB3aGljaCBjYW4gYmUgdXNlZCB0byBkaXNjb3ZlciBpbmZvcm1hdGlvbiBhYm91dCBwZW9wbGUg b3Igb3RoZXI8YnI+DQomZ3Q7Jmd0OyZndDsgZW50aXRpZXMgb24gdGhlIEludGVybmV0IHVzaW5n IHN0YW5kYXJkIEhUVFAgbWV0aG9kcy4mbmJzcDsgV2ViRmluZ2VyPGJyPg0KJmd0OyZndDsmZ3Q7 IGRpc2NvdmVycyBpbmZvcm1hdGlvbiBmb3IgYSBVUkkgdGhhdCBtaWdodCBub3QgYmUgdXNhYmxl IGFzIGE8YnI+DQomZ3Q7Jmd0OyZndDsgbG9jYXRvciBvdGhlcndpc2UsIHN1Y2ggYXMgYWNjb3Vu dCBvciBlbWFpbCBVUklzLjxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgPGJy Pg0KJmd0OyZndDsmZ3Q7IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlz IGRyYWZ0IGlzOiA8YnI+DQomZ3Q7Jmd0OyZndDsgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtaWV0Zi1hcHBzYXdnLXdlYmZpbmdlcjxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+ DQomZ3Q7Jmd0OyZndDsgVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUg YXQ6IDxicj4NCiZndDsmZ3Q7Jmd0OyBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLWFwcHNhd2ctd2ViZmluZ2VyLTEwPGJyPg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7 Jmd0OyBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6IDxi cj4NCiZndDsmZ3Q7Jmd0OyBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1p ZXRmLWFwcHNhd2ctd2ViZmluZ2VyLTEwPGJyPg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7 Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJs ZSBieSBhbm9ueW1vdXMgRlRQIGF0OiA8YnI+DQomZ3Q7Jmd0OyZndDsgZnRwOi8vZnRwLmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy88YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7 IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIGFwcHMtZGlz Y3Vzczxicj4NCiZndDsmZ3Q7Jmd0OyBtYWlsaW5nIGxpc3QgYXBwcy1kaXNjdXNzQGlldGYub3Jn IDxicj4NCiZndDsmZ3Q7Jmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2FwcHMtZGlzY3Vzczxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIHdlYmZpbmdlciBtYWlsaW5nPGJyPg0K Jmd0OyZndDsgbGlzdCB3ZWJmaW5nZXJAaWV0Zi5vcmcgPGJyPg0KJmd0OyZndDsgaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby93ZWJmaW5nZXI8YnI+DQomZ3Q7Jmd0OyA8YnI+ DQomZ3Q7IDxicj4NCiZndDsgLS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS08YnI+DQomZ3Q7 IFZlcnNpb246IEdudVBHL01hY0dQRzIgdjIuMC4xOCAoRGFyd2luKTxicj4NCiZndDsgQ29tbWVu dDogVXNpbmcgR251UEcgd2l0aCBUaHVuZGVyYmlyZCAtIGh0dHA6Ly93d3cuZW5pZ21haWwubmV0 Lzxicj4NCiZndDsgPGJyPg0KJmd0OyBpUUljQkFFQkFnQUdCUUpSRmRBcUFBb0pFT29HcEpFcnhh MnBmSU1QLzNSYXplTW5jMGxDYXBlUmpaMEdTTC8zPGJyPg0KJmd0OyBycGdYRkJ0cG5JSGxMTm04 VTQ1ejlscnpuJiM0Mzt6NE0xc0p3aVVUVXNXRk1RV0tOcC8mIzQzO0VIZ29pbWR2dnd0VUEmIzQz O1JqPGJyPg0KJmd0OyB2JiM0MztGV1lYMDNCYnROdHhlZGZhaWIzLzZZJiM0MztXWjZQaThFSFo3 RS9NdHNGYXVVRTJXWVpNMkhYL2FDRjhWVVBLQk88YnI+DQomZ3Q7IFYzV0RPUEFwYmxiZll3Z3A4 ZFJXb2VCT1Y2JiM0MztBTmJ6cEVpZU1oWDFScTFSUEZOTXRuNnRTSUpRTnJiTVVlcWlsPGJyPg0K Jmd0OyB0eXVCVFVIbGxhVW00WTlGMTVFdkVnRHBiY3d1VEtqYXZVUUtnZDZiTVZSeThsTHl0ZXZH Vm5CSmxKSWVIR1JjPGJyPg0KJmd0OyBDR2phNHEvVWVTVDcvR3h3WWp3Um5nV1A0SEMvRUV0MUI3 Vm1GRi9ha0E4QlRocmxDNHk2TG9ieHpLNkpOLzMyPGJyPg0KJmd0OyBuN0FsVm5pcDFVVzFyVGZT dFY0akUxY2dMOGFrV04xVUg1a1pYaEpZUE9ieTc5Y2h0cXhGVENhcEZCZmlCaERLPGJyPg0KJmd0 OyBsaHFVamN5OWVhVHhUeXByUmxJQ0EmIzQzOzNURFBPSGNFVCYjNDM7ZHJ2TjVFRG9UOWkxUzBv MXdLYnVrYkwmIzQzO0t1QnRyQ1VMPGJyPg0KJmd0OyBQYTlLVE5DdFVaSDVWUVA4VkFJaDMzZEUw RmsmIzQzOy9KUWZUQ3VmWFJsR3lJRTNBL3ZYZ0QvV3Zka2pXenJhNmtxTDxicj4NCiZndDsgZkhL N2VLeS8wQm9EWVZkYWt5bkFXWnlRVmtBckJzTVpMdlhLUXhqMTg0MU9aMUZpa082TzkzRktORWRV dzRIdjxicj4NCiZndDsgV2xwJiM0Mzt0YUNQZmU1JiM0Mzt3NDFnM1lJbGJSZWxEN1JQd3BCTXZJ MzU2NiYjNDM7JiM0MztLeENkcUpIYXV5ZVRWS01PNExlbndHMXU8YnI+DQomZ3Q7IE1scFRlak1O TTlJVkZSRzVxeEZ2PGJyPg0KJmd0OyA9Wk5tNDxicj4NCiZndDsgLS0tLS1FTkQgUEdQIFNJR05B VFVSRS0tLS0tPGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCiZndDsgd2ViZmluZ2VyIG1haWxpbmcgbGlzdDxicj4NCiZndDsgd2Vi ZmluZ2VyQGlldGYub3JnPGJyPg0KJmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3dlYmZpbmdlcjxicj4NCiZndDsgPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQp3ZWJmaW5nZXIgbWFpbGluZyBsaXN0 PGJyPg0Kd2ViZmluZ2VyQGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby93ZWJmaW5nZXI8YnI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_4E1F6AAD24975D4BA5B16804296739436742343DTK5EX14MBXC284r_-- From bradfitz@google.com Mon Feb 11 11:32:36 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 7E62521F8651 for ; Mon, 11 Feb 2013 11:32:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id toqjQDOggmRI for ; Mon, 11 Feb 2013 11:32:35 -0800 (PST) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id D7D6521F87D2 for ; Mon, 11 Feb 2013 11:32:34 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id fg15so4860205wgb.25 for ; Mon, 11 Feb 2013 11:32:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=dL5ui6rz/jfkxMXvNArdrAqEAaejdBMiL2GnVBEKILU=; b=GZ6Fg6ehr4F6oNCiFB4RBckD/OlH1gvLJP2pZd5+ZDX2ly7Y+Ghb3ymLzgI6gV2kpq 37iMZLPyUZGFbHY4sH04x2s3BYLBWJKEXeHxi1vu58ewbxqT8tT/IIQsws76xLpGUS+/ 6Z1Hb+wP8BUeambHE4Af1pRv7EdwP95s4JTLCc6XoWBggZXnkQnRw185f9xTxaBE5rOi NqIlD8h6TsAiRHsreChXf/CL+948PoG92SeqnkuL6sfj5QHUikEXTAlMjZtnX/RKk//m P0pFzrvQs5s8W4tgBYncR7u7HegpxxKkZNUj9C3GnlE46VAkI5Sp1ukHDVC5eo4GUbRQ 0MoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=dL5ui6rz/jfkxMXvNArdrAqEAaejdBMiL2GnVBEKILU=; b=Nsn7dbAae69DR2m9eW6d4KCoMLRpOL9C03znq2ToyEudW8WKLPybW/mHWB0uwd9Nex 6+bsK+9Ymj5wJlZUVkT2RkpcgNGIKeY/wnFHmfUZa/47rtRQPT2caGcdZnSSFqDmU7bV dirEPBBdkpBU8DH0Ji779teZLy8ZFBQ5mKkJBjhTTBhQ/zvTqIkR4QxpWXTPnigqmevv 8sPBLj/f4vl4V56TYaS2H4jZmjx7DcWq1XXMblPRLAGrEGfncuz8BzJSrJn0TeFXrRY2 MZngF5l0qJJx9WfAHYRTkcJyAWZnVRPVwkUQOgloO9fE118EKm91djUzLxwEPgZdnjkY hNjg== MIME-Version: 1.0 X-Received: by 10.180.83.227 with SMTP id t3mr18405987wiy.2.1360611153897; Mon, 11 Feb 2013 11:32:33 -0800 (PST) Received: by 10.194.170.231 with HTTP; Mon, 11 Feb 2013 11:32:33 -0800 (PST) In-Reply-To: <028d01ce067d$32872780$97957680$@packetizer.com> References: <20130209033118.8995.1805.idtracker@ietfa.amsl.com> <028d01ce067d$32872780$97957680$@packetizer.com> Date: Mon, 11 Feb 2013 11:32:33 -0800 Message-ID: From: Brad Fitzpatrick To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=f46d0421a64f81679a04d577f8e2 X-Gm-Message-State: ALoCoQkAY8z6elq0uZoVlkwwp06vEozyl8ujzY9yuOxnlbkMAi2+PXyiz2Jq2va1kxc+6scJlaiYCi8IcXpp8iCd+qRTi5GWTrrx0e0ZpH26VhE9HnZkXZPGWX3n7AbiTKLkdP9PMyby8/zaD9lmwM1XKu3HAt/0DdgHzKvEFHneSBFcvzqOVhn3E2C+L4khHEOZu71zYBzG Cc: webfinger@ietf.org Subject: Re: [webfinger] FW: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-10.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: Mon, 11 Feb 2013 19:32:37 -0000 --f46d0421a64f81679a04d577f8e2 Content-Type: text/plain; charset=UTF-8 +1 Ended up nice and simple. :-) On Fri, Feb 8, 2013 at 8:23 PM, Paul E. Jones wrote: > Folks, > > I tried to accurately reflect all of the suggested editorial and technical > changes. > > The only "technical" changes were: > * Removal of the "expires" member from the JRD object > * Introduction of the application/jrd+json media type > > Please have a look over this version and let me know if you find any > issues. > If there are none, we may be set to move this along. > > Paul > > > -----Original Message----- > > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > > bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > > Sent: Friday, February 08, 2013 10:31 PM > > To: i-d-announce@ietf.org > > Cc: apps-discuss@ietf.org > > Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-10.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Applications Area Working Group > > Working Group of the IETF. > > > > Title : WebFinger > > Author(s) : Paul E. Jones > > Gonzalo Salgueiro > > Joseph Smarr > > Filename : draft-ietf-appsawg-webfinger-10.txt > > Pages : 22 > > Date : 2013-02-08 > > > > Abstract: > > This specification defines the WebFinger protocol, which can be used > > to discover information about people or other entities on the > > Internet using standard HTTP methods. WebFinger discovers > > information for a URI that might not be usable as a locator > > otherwise, such as account or email URIs. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-10 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-webfinger-10 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > -- > > --- > You received this message because you are subscribed to the Google Groups > "WebFinger" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to webfinger+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > --f46d0421a64f81679a04d577f8e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1

Ended up nice and simple. =C2=A0:-)


On Fri, Feb 8, 2013 at 8:23 PM, Paul E. Jones <paulej= @packetizer.com> wrote:
Folks,

I tried to accurately reflect all of the suggested editorial and technical<= br> changes.

The only "technical" changes were:
=C2=A0* Removal of the "expires" member from the JRD object
=C2=A0* Introduction of the application/jrd+json media type

Please have a look over this version and let me know if you find any issues= .
If there are none, we may be set to move this along.

Paul

> -----Original Message-----
> From: apps-discuss-bo= unces@ietf.org [mailto:apps-discuss-
> bounces@ietf.org] On Behalf Of= internet-drafts@ietf.org > Sent: Friday, February 08, 2013 10:31 PM
> To: i-d-announce@ietf.org=
> Cc: apps-discuss@ietf.org=
> Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-10.tx= t
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> =C2=A0This draft is a work item of the Applications Area Working Group=
> Working Group of the IETF.
>
> =C2=A0 =C2=A0 =C2=A0 Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : WebFin= ger
> =C2=A0 =C2=A0 =C2=A0 Author(s) =C2=A0 =C2=A0 =C2=A0 : Paul E. Jones > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Gonzalo Salgueiro
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Joseph Smarr
> =C2=A0 =C2=A0 =C2=A0 Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-ietf-= appsawg-webfinger-10.txt
> =C2=A0 =C2=A0 =C2=A0 Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 22
> =C2=A0 =C2=A0 =C2=A0 Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 2= 013-02-08
>
> Abstract:
> =C2=A0 =C2=A0This specification defines the WebFinger protocol, which = can be used
> =C2=A0 =C2=A0to discover information about people or other entities on= the
> =C2=A0 =C2=A0Internet using standard HTTP methods. =C2=A0WebFinger dis= covers
> =C2=A0 =C2=A0information for a URI that might not be usable as a locat= or
> =C2=A0 =C2=A0otherwise, such as account or email URIs.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-appsawg-w= ebfinger
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-= 10
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ap= psawg-webfinger-10
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp:= //ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

--

---
You received this message because you are subscribed to the Google Groups &= quot;WebFinger" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to webfing= er+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.



--f46d0421a64f81679a04d577f8e2-- From bobwyman@gmail.com Mon Feb 11 16:53:19 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 DD2A221F8782 for ; Mon, 11 Feb 2013 16:53:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MIc+Djt8aed0 for ; Mon, 11 Feb 2013 16:53:18 -0800 (PST) Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) by ietfa.amsl.com (Postfix) with ESMTP id C3EEC21F8780 for ; Mon, 11 Feb 2013 16:53:16 -0800 (PST) Received: by mail-wg0-f48.google.com with SMTP id 16so5115206wgi.3 for ; Mon, 11 Feb 2013 16:53:15 -0800 (PST) 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=LLSQnvBgR3Koc+nqNrZEhnb2OeLos7URKOqi/Eu2UeE=; b=YxrDAZIxxZT9SCm/xvjWrUIa3/5q2MKLO9eObYceVbLNmm3QSY6mtcSBMv41fhw0ns hdQh/bGaBiNf9yuQh/ASW0G+zGmSeahna5Ztulc7Cz9KuTf6L4w4PhYeqRLxtgX9qjAq k+G1zDwJjm8f802g7iPZcC4HOZ+x0vx4J8yTtEiIgxXFWNlEiDVAz8ej1+2OlKLyIGaP EahH77vwRuZl9RgQ+cOndPfJox8l/n1QaMfUh18HIK7Y5F+nq/ar9Nzyu8PCXlOtpfKv 9raEkGr/OClvkVzkfF44Ms/rV8mLPwBD0Pq7Amib1uv9H68CwNMAxMlaqRG78T6sn9Di YuuQ== MIME-Version: 1.0 X-Received: by 10.194.23.37 with SMTP id j5mr27491024wjf.28.1360630395327; Mon, 11 Feb 2013 16:53:15 -0800 (PST) Sender: bobwyman@gmail.com Received: by 10.194.15.137 with HTTP; Mon, 11 Feb 2013 16:53:15 -0800 (PST) In-Reply-To: References: <20130209033118.8995.1805.idtracker@ietfa.amsl.com> <028d01ce067d$32872780$97957680$@packetizer.com> Date: Mon, 11 Feb 2013 19:53:15 -0500 X-Google-Sender-Auth: XyXkD0VVWvMKRZ1VWmdD_oHp2qA Message-ID: From: Bob Wyman To: WebFinger List Content-Type: multipart/alternative; boundary=047d7b414e8c62541004d57c7367 Cc: webfinger@ietf.org Subject: Re: [webfinger] FW: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-10.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: Tue, 12 Feb 2013 00:53:19 -0000 --047d7b414e8c62541004d57c7367 Content-Type: text/plain; charset=ISO-8859-1 +1 at last... On Mon, Feb 11, 2013 at 2:32 PM, Brad Fitzpatrick wrote: > +1 > > Ended up nice and simple. :-) > > > On Fri, Feb 8, 2013 at 8:23 PM, Paul E. Jones wrote: > >> Folks, >> >> I tried to accurately reflect all of the suggested editorial and technical >> changes. >> >> The only "technical" changes were: >> * Removal of the "expires" member from the JRD object >> * Introduction of the application/jrd+json media type >> >> Please have a look over this version and let me know if you find any >> issues. >> If there are none, we may be set to move this along. >> >> Paul >> >> > -----Original Message----- >> > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- >> > bounces@ietf.org] On Behalf Of internet-drafts@ietf.org >> > Sent: Friday, February 08, 2013 10:31 PM >> > To: i-d-announce@ietf.org >> > Cc: apps-discuss@ietf.org >> > Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-10.txt >> > >> > >> > A New Internet-Draft is available from the on-line Internet-Drafts >> > directories. >> > This draft is a work item of the Applications Area Working Group >> > Working Group of the IETF. >> > >> > Title : WebFinger >> > Author(s) : Paul E. Jones >> > Gonzalo Salgueiro >> > Joseph Smarr >> > Filename : draft-ietf-appsawg-webfinger-10.txt >> > Pages : 22 >> > Date : 2013-02-08 >> > >> > Abstract: >> > This specification defines the WebFinger protocol, which can be used >> > to discover information about people or other entities on the >> > Internet using standard HTTP methods. WebFinger discovers >> > information for a URI that might not be usable as a locator >> > otherwise, such as account or email URIs. >> > >> > >> > The IETF datatracker status page for this draft is: >> > https://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger >> > >> > There's also a htmlized version available at: >> > http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-10 >> > >> > A diff from the previous version is available at: >> > http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-webfinger-10 >> > >> > >> > Internet-Drafts are also available by anonymous FTP at: >> > ftp://ftp.ietf.org/internet-drafts/ >> > >> > _______________________________________________ >> > apps-discuss mailing list >> > apps-discuss@ietf.org >> > https://www.ietf.org/mailman/listinfo/apps-discuss >> >> -- >> >> --- >> You received this message because you are subscribed to the Google Groups >> "WebFinger" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to webfinger+unsubscribe@googlegroups.com. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > -- > > --- > You received this message because you are subscribed to the Google Groups > "WebFinger" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to webfinger+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > --047d7b414e8c62541004d57c7367 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+1

at last...


On Mon, Feb 11, 2013 = at 2:32 PM, Brad Fitzpatrick <bradfitz@google.com> wrote:<= br>
+1

Ended up nice and simple. =A0:-)<= /div>


On Fri, Feb 8, 2013 at 8:23 PM, Paul E. Jones <paulej@packetizer.com> wrote:
Folks,

I tried to accurately reflect all of the suggested editorial and technical<= br> changes.

The only "technical" changes were:
=A0* Removal of the "expires" member from the JRD object
=A0* Introduction of the application/jrd+json media type

Please have a look over this version and let me know if you find any issues= .
If there are none, we may be set to move this along.

Paul

> -----Original Message-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
> bounces@ietf.org= ] On Behalf Of internet-drafts@ietf.org
> Sent: Friday, February 08, 2013 10:31 PM
> To: i-d-ann= ounce@ietf.org
> Cc: apps-di= scuss@ietf.org
> Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-10.tx= t
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> =A0This draft is a work item of the Applications Area Working Group > Working Group of the IETF.
>
> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : WebFinger
> =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Paul E. Jones
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Gonzalo Salgueiro<= br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Joseph Smarr
> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-appsawg-webfinger-10.= txt
> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 22
> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-02-08
>
> Abstract:
> =A0 =A0This specification defines the WebFinger protocol, which can be= used
> =A0 =A0to discover information about people or other entities on the > =A0 =A0Internet using standard HTTP methods. =A0WebFinger discovers > =A0 =A0information for a URI that might not be usable as a locator
> =A0 =A0otherwise, such as account or email URIs.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-appsawg-w= ebfinger
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-= 10
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ap= psawg-webfinger-10
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp:= //ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> apps-discuss mailing list
> apps-discus= s@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

--

---
You received this message because you are subscribed to the Google Groups &= quot;WebFinger" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to webfinger+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.



--
=A0
---
You received this message because you are subscribed to the Google Groups &= quot;WebFinger" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to webfinger+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
=A0
=A0

--047d7b414e8c62541004d57c7367-- From evan@e14n.com Mon Feb 11 18:58:20 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 DC17F21F87E3 for ; Mon, 11 Feb 2013 18:58:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pG-ash8feKBg for ; Mon, 11 Feb 2013 18:58:20 -0800 (PST) Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id 46B9821F87C3 for ; Mon, 11 Feb 2013 18:58:20 -0800 (PST) Received: from [192.168.0.107] (modemcable218.194-202-24.mc.videotron.ca [24.202.194.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id A441E8D44C3; Tue, 12 Feb 2013 03:12:30 +0000 (UTC) Message-ID: <5119AFC8.5070406@e14n.com> Date: Mon, 11 Feb 2013 21:58:16 -0500 From: Evan Prodromou Organization: E14N User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "webfinger@ietf.org" , "webfinger@googlegroups.com" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050807070801020009020003" Subject: [webfinger] Webfinger and RFC 6415 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, 12 Feb 2013 02:58:21 -0000 This is a cryptographically signed message in MIME format. --------------ms050807070801020009020003 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable If a server supports Web Host Metadata per RFC 6415, it can easily use=20 the Webfinger endpoint as a JRD-serving LRDD link. You can make your=20 /.well-known/host-meta.json (JRD-serving host-wide metadata) look=20 something like this: { "links": [ { "rel": "lrdd", "type": "application/json", "template":=20 "http://example.com/.well-known/webfinger?resource=3D{uri}" } ] } Supporting this usage was an important part of how we got to the current = structure, but we don't mention it in the current draft. It can be documented elsewhere, but it might be useful in the document=20 itself. Definitely not a blocker, but I wanted to bring it up. -Evan --------------ms050807070801020009020003 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMQTCC BUswggQzoAMCAQICEEuui3coSgPxeBmm1kzS1rswDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAe Fw0xMjExMjEwMDAwMDBaFw0xMzExMjEyMzU5NTlaMIIBDjEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52 ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMp OTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJ RCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRcwFQYDVQQDFA5FdmFuIFByb2Ry b21vdTEcMBoGCSqGSIb3DQEJARYNZXZhbkBlMTRuLmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAORmFCsNPJqt5UyhR02QZdZdUxvxQcPqu4jsZ6OEHSN5B+fUGFp87FLq 4PJZwfIu1Cv4QItq4AmIvVJi8AbrbBBNN45jzZvPNFCA7lvihd47aviNpfOdm0mx3YYfH+aU 4W5oXdSrCaIqWwAjxUnYWaJljCXi7kd9t4zL9mnl+W+IKw3L5sT2CWZpapAmCI+xO41PhLEJ hyBWrQKgSwjINgJgoEVOhVien2v5pe3FxWGDRuS3UWiRHFPg+ZjmQIvmR6KJ5l3esRl7y1L2 QbNGlSC92LAW1MXDSo5T0WCypZs93NFBvcfsOcdWVBS+1p1gycpGtkDio5Itgqv2IzBA8c0C AwEAAaOB0jCBzzAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggr BgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMFAGA1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9p bmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELUczLmNy bDANBgkqhkiG9w0BAQUFAAOCAQEAPaHFMHt2vp6k7gmYqDdvn1upM2aJ2sVX4ybGJME97Hrg /axsoTmtY69LtfTNHqOJAbjXgaqABXp9f+p1JqzI5Nkaac2rWDx2BFGUdUuQKeIzyiAPJ0Ou wWNBThLS/tTUuipWx2V0jIJzPRP0gZuxBi6JQydnLsWEMZeup5jC8QhXCSPu1aaJ08SbdYCD xYSpHUoPkpOxm7A/Vx4xN24edU0TvmH+xvXPMo3NgPNs+Qsjt2Tugg2O6XngESdsE/X9+JMC aDRyDaC1oUe8TytFkOJvJ2AplXVwr5h3pI3IoDoq1EX86MZjf3QiloN2Qn0ELsIRcPkQZPeM +O2qklmEJTCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEFBQAw gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4g LSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQ dWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAw MDAwMFoXDTE5MDQzMDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2ln biwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVy bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJ bmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAO3ER98qKB18Bmu71yEyyWwTj+mxjUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBf DUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliWB6+eFBgHT1q9n9IxslQZc0ZqGUIR7BJzIY31 3DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGcedAATDdCG2pNn+DMDrho8a2l49sAsjuGD P3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69ssQRevsG2lC2XkC0n0rse6YNqhPbE sq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOMWev7btVCxL5Bx/UCAwEAAaOC ArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AudmVyaXNp Z24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtghkgBhvhFAQcXATBW MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoGCCsGAQUFBwIC MB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCegJYYjaHR0 cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4GCCsG AQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy7 0FI4mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAu BgNVHREEJzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4E FgQUeUdhCEH9OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRo b3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmlt YXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0G CSqGSIb3DQEBBQUAA4IBAQA5Tc9BmYG1qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGT gc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN7/HSgZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw8 4J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqTOtWuEnAI6/s74nfs6CtkNXbNutrg0csU1nFY m77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih/1yybUneZVJC+w6I0u1KHb9L4/jMcvpI DmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0DuFUWjMZoA+ciqHMLsbyg2lJY3QoO f8GCMYIE+TCCBPUCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMg b2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsT FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQS66LdyhKA/F4GabWTNLWuzAJBgUrDgMCGgUA oIIC2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzAyMTIw MjU4MTZaMCMGCSqGSIb3DQEJBDEWBBT3qswRtUR+9hTdvEGHsWDbrf6JpTBsBgkqhkiG9w0B CQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVz ZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJz b25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzMCEEuui3coSgPxeBmm1kzS1rswggEFBgsqhkiG9w0BCRAC CzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQg aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEczAhBLrot3KEoD8XgZptZM0ta7MA0GCSqGSIb3DQEBAQUABIIBAAl3 Vj/m/o0IvxHjoQUY99+mrnNzsgYx3cAI72gxK95vfBeh2L4KDajpdSVxWmFU9CIVUv6DCq9G h05ECmXBpJ5afIZ4hqA8bGYzhWX23dqbUdI55h7xIHtNjiVl0DsI5gDEI4Gtdjbwx9Z65O5c 0Olu21SxlsWblCk3Me6tVmQlqrGKDp0lecUFbLeYImBQA0faXjEglkT9bhMODFgIYPrt5/17 rc8+hftmnWUIX9QVxezv1msGxrj5UIgxpIgnM11zzNmI/OrQ6pqLzM8PsUTZsiLaENb1t92+ m6ywAAAnCq3oINFkvz9cqNKdp2RoOhpzFH7AI+kIrVcf7Lw5HjIAAAAAAAA= --------------ms050807070801020009020003-- From paulej@packetizer.com Wed Feb 13 01:35: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 7195621F8826 for ; Wed, 13 Feb 2013 01:35:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.777 X-Spam-Level: X-Spam-Status: No, score=-1.777 tagged_above=-999 required=5 tests=[AWL=-0.668, BAYES_05=-1.11, 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 Nh443cwLpXM1 for ; Wed, 13 Feb 2013 01:35:25 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id CCE1021F882D for ; Wed, 13 Feb 2013 01:35:21 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r1D9ZKFB016246 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 13 Feb 2013 04:35:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1360748120; bh=p//z+EmljbOwgZ+8cx7pKQTY+fK0AY2EcMKem9xdVm8=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; b=EMogjoFcuFil+FB54k+/5nib3n/gjF/cv56McbY8vj+E5ucrQgRVvsTCrVvNq2MY9 3MHiBqSKFX/uUWoXPBXoo2APd9gAIGFZd/E/tGt1SidqnGru0epxhkG9bOWYGAOoYc /yU85Ma5kdMwrkrLWY9hLJULZzvZ/3++RCZKwkVY= From: "Paul E. Jones" To: , Date: Wed, 13 Feb 2013 04:35:31 -0500 Message-ID: <02ec01ce09cd$77cbbe70$67633b50$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02ED_01CE09A3.8EF62BA0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4Jy1+6ZEsFmWwwQLee1fsrrRXnmg== Content-Language: en-us Subject: [webfinger] WebFinger 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: Wed, 13 Feb 2013 09:35:26 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02ED_01CE09A3.8EF62BA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Folks, As promised, I'm making my WebFinger server software available for those who want to set up their own server. You can find a link to the package on this page: http://www.packetizer.com/webfinger/server.html This software implements both WebFinger (current draft) and Host Metadata (RFC 6415), including LRDD. It will return XRD or JRD as requested by the client, but will also return the correct document type by default if nothing is requested explicitly. Since it does it all, it is a bit more complex than if it only implemented the WebFinger draft. That said, I didn't think it was too much to just do everything, and so I did. The code is written in Perl and intended for use with Apache, but it does not use any advanced Perl or Apache capabilities, so it should port with a little effort. The code is a simple CGI script about 1100 lines long or so. I have no idea how well it will scale, but scale was not my objective. If I was seeking higher scale, I would have turned it into an FCGI script, at the very least. I just wanted something that fit well within my environment. If it fits well in yours, great :-) I was constantly updating this code to align with the ever-changing spec. It seems to be settling down now, so I felt comfortable publishing it. While I've tested the code quite a bit while writing the spec, I do not want to say it is flawless. It's an initial release, so do expects some bumps. (That's especially true for the documentation, since I just wrote it in a hurry knowing I'll not have time to do it for the next few weeks.) Feel free to send me questions or comments if you have any. I'll be around off and on during the week, so please accept my apologies if my response not immediate. Paul ------=_NextPart_000_02ED_01CE09A3.8EF62BA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

As promised, = I’m making my WebFinger server software available for those who = want to set up their own server.  You can find a link to the = package on this page:

http://www.packe= tizer.com/webfinger/server.html

 

This = software implements both WebFinger (current draft) and Host Metadata = (RFC 6415), including LRDD.  It will return XRD or JRD as requested = by the client, but will also return the correct document type by default = if nothing is requested explicitly.  Since it does it all, it is a = bit more complex than if it only implemented the WebFinger draft.  = That said, I didn’t think it was too much to just do everything, = and so I did.

 

The code is written in Perl and intended for use with = Apache, but it does not use any advanced Perl or Apache capabilities, so = it should port with a little effort.  The code is a simple CGI = script about 1100 lines long or so.  I have no idea how well it = will scale, but scale was not my objective.  If I was seeking = higher scale, I would have turned it into an FCGI script, at the very = least.  I just wanted something that fit well within my = environment.  If it fits well in yours, great :-)

 

I was = constantly updating this code to align with the ever-changing = spec.  It seems to be settling down now, so I felt comfortable = publishing it.  While I’ve tested the code quite a bit while = writing the spec, I do not want to say it is flawless.  It’s = an initial release, so do expects some bumps.  (That’s = especially true for the documentation, since I just wrote it in a hurry = knowing I’ll not have time to do it for the next few = weeks.)

 

Feel free to send me questions or comments if you have = any.  I’ll be around off and on during the week, so please = accept my apologies if my response not immediate.

 

Paul

 

------=_NextPart_000_02ED_01CE09A3.8EF62BA0-- From kidehen@openlinksw.com Thu Feb 14 04:35: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 7038C21F86AB for ; Thu, 14 Feb 2013 04:35:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqQ2n4UIZ+7i for ; Thu, 14 Feb 2013 04:35:28 -0800 (PST) Received: from mail.openlinksw.com (mail.openlinksw.com [63.119.36.38]) by ietfa.amsl.com (Postfix) with ESMTP id 1CDF221F869A for ; Thu, 14 Feb 2013 04:35:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=openlinksw.com; s=x; h=Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=7GSE1REMFe9bpGT6ux0lz9GCdkB0Pi6sE127ZfuMBHE=; b=UoQGP3EaYCkUV/w38DiA6RUReylwgHpoGYAMNJjz5NwXD1T9TUBZs2Ycmyh+OwoL+J3etNyKsv3RVpzCS0uMO+0u26jDtCGM64JxWQaf0L+9ZpznucTw36RoBvsKG5c4; Received: from pool-173-48-165-129.bstnma.fios.verizon.net ([173.48.165.129] helo=macintosh-96.home) by mail.openlinksw.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.74) (envelope-from ) id 1U5y2A-00021R-Fq for webfinger@ietf.org; Thu, 14 Feb 2013 07:35:26 -0500 Message-ID: <511CDA0D.7060007@openlinksw.com> Date: Thu, 14 Feb 2013 07:35:25 -0500 From: Kingsley Idehen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: webfinger@ietf.org References: <5119AFC8.5070406@e14n.com> In-Reply-To: <5119AFC8.5070406@e14n.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060808080103090204030601" Subject: Re: [webfinger] Webfinger and RFC 6415 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, 14 Feb 2013 12:35:30 -0000 This is a cryptographically signed message in MIME format. --------------ms060808080103090204030601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 2/11/13 9:58 PM, Evan Prodromou wrote: > If a server supports Web Host Metadata per RFC 6415, it can easily use = > the Webfinger endpoint as a JRD-serving LRDD link. You can make your=20 > /.well-known/host-meta.json (JRD-serving host-wide metadata) look=20 > something like this: > > { > "links": [ > { > "rel": "lrdd", > "type": "application/json", > "template":=20 > "http://example.com/.well-known/webfinger?resource=3D{uri}" > } > ] > } > > Supporting this usage was an important part of how we got to the=20 > current structure, but we don't mention it in the current draft. > > It can be documented elsewhere, but it might be useful in the document = > itself. Definitely not a blocker, but I wanted to bring it up. > > -Evan +1 We support this pattern in our servers. --=20 Regards, Kingsley Idehen=09 Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca handle: @kidehen Google+ Profile: https://plus.google.com/112399767740508618350/about LinkedIn Profile: http://www.linkedin.com/in/kidehen --------------ms060808080103090204030601 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEJDCC BCAwggMIoAMCAQICAgE4MA0GCSqGSIb3DQEBDQUAMEExIzAhBgNVBAMMGk9wZW5MaW5rIFNv ZnR3YXJlIExvY2FsIENBMRowGAYDVQQKDBFPcGVuTGluayBTb2Z0d2FyZTAeFw0xMjAyMjQx OTU2NTlaFw0xMzAyMjMxOTU2NTlaMHExHTAbBgNVBAMUFEBraWRlaGVuIChMaW5rZWRJbikg MSkwJwYDVQQKEyBQZXJzb25hbCBEYXRhIFNwYWNlIHZpYSBMaW5rZWRJbjElMCMGCSqGSIb3 DQEJARYWa2lkZWhlbkBvcGVubGlua3N3LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAKrT1qMDcB84exoG2vBpCkJW0LclRLuM0gnbqnY+e/aBhJGtlwAtgvHehFwWT/ec 1jDTKEkgmJMGQaBwiM+BslcRIO1DdebUEwTI2HpY1PzCarGir+4lxPySTc9Wb8Y77k6eId20 pC2DhMa3dwLWbUColYPbcwCLhl+dD8g9GVDpuuqhQpFd24M5ycV62GMbjQi2pLlqXE9eQgOy NpOeSO4GCOlTX4N84YWFXQw9OpMu3NN3Gebd0czpwHK/sgHpQGGCZTfCUfkXhXwb5MuYYnHr pwIpsWU3aD7PMO4UJeAGnI3A/mC0vbvBRBLflgGMMqk6r4EGMhjhtSYEo2i+VX0CAwEAAaOB 8TCB7jAdBgNVHQ4EFgQUxyi+Y4xfaXWdVzdTTGn2clQ/r5YwbAYDVR0RBGUwY4ZJaHR0cDov L2lkLm15b3BlbmxpbmsubmV0L2Fib3V0L2lkL2VudGl0eS9odHRwL3d3dy5saW5rZWRpbi5j b20vaW4va2lkZWhlboEWa2lkZWhlbkBvcGVubGlua3N3LmNvbTAtBglghkgBhvhCAQ0EIBYe VmlydHVvc28gR2VuZXJhdGVkIENlcnRpZmljYXRlMCAGA1UdJQEB/wQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQENBQADggEBAFrH60IIx9mG LxLVxZ81c2ti3gPU18j8GvbhHk7jNRWPepeR99T49K+YdUwMAPvsypfxS0f77CYM2JwCFkus rCr+NyVR44cvdXOYQcAlmlklDu+U+bZMLYWAzgx0U5kLZunFXBpoXUxuC5uVVhZ4cX/GrkYh 7JlEnqg1GgDnIjgojV4gc8a2oTEGA+eNY72N29MO0I9Ptu72HY13VT3tkPmOpCBMKJbDCfVF dUJeLv7AnNFSA28lg0x1bwjTixavzFbkpkdjmdSYfxPJRkzUgATcfNGQbdwMhz4Smd921wFL oorFXA2tGuMwkNePnD/Wg73BbtAhHGMNq575tPdysVIxggLvMIIC6wIBATBHMEExIzAhBgNV BAMMGk9wZW5MaW5rIFNvZnR3YXJlIExvY2FsIENBMRowGAYDVQQKDBFPcGVuTGluayBTb2Z0 d2FyZQICATgwCQYFKw4DAhoFAKCCAX0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMTMwMjE0MTIzNTI1WjAjBgkqhkiG9w0BCQQxFgQUk0V9K2A7e74e+q5l 2p632vwNRw4wVgYJKwYBBAGCNxAEMUkwRzBBMSMwIQYDVQQDDBpPcGVuTGluayBTb2Z0d2Fy ZSBMb2NhbCBDQTEaMBgGA1UECgwRT3BlbkxpbmsgU29mdHdhcmUCAgE4MFgGCyqGSIb3DQEJ EAILMUmgRzBBMSMwIQYDVQQDDBpPcGVuTGluayBTb2Z0d2FyZSBMb2NhbCBDQTEaMBgGA1UE CgwRT3BlbkxpbmsgU29mdHdhcmUCAgE4MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEq MAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwIC AUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAS4vhMsSXG64X ixIXLu0DJFYOH+wAhrfBRgAYiTcLgsMvpIGQyor+L6QEzUr1lK38jvq/TJEAkA9goj66bZdI FB/Rl3NRekNA55XTgkovJFwrf7+nrajev5lOw+rnHBaaWUwrNu6VCm6nwCplWt4V87DY5UjZ 4u6VKMlzYv1nrFi3xtfAdEzICMOxPknbrLX5SOYi4vyOkI1bE0SIgWvvnmIIRgwCMLJZBzlx dOcSKJ8jVfNUJonk7S4NR5AXOgt4BPFkq8ntng3mqzHVrgYZyo73P4HBQ7WmCYYqTcDKygqq yNCOfZ0kFH4zlcr6Qznx957S7oWOYDVYwS066zqgVwAAAAAAAA== --------------ms060808080103090204030601-- From laurentwalter.goix@telecomitalia.it Thu Feb 14 05:25:21 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 0E6FB21F87A4 for ; Thu, 14 Feb 2013 05:25:21 -0800 (PST) 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=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4I5AGSk1-G6V for ; Thu, 14 Feb 2013 05:25:20 -0800 (PST) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id EB4A721F84A1 for ; Thu, 14 Feb 2013 05:25:19 -0800 (PST) Received: from grfhub704ba020.griffon.local (10.188.101.117) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.3.297.1; Thu, 14 Feb 2013 14:25:12 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by grfhub704ba020.griffon.local ([10.188.101.117]) with mapi; Thu, 14 Feb 2013 14:25:12 +0100 From: Goix Laurent Walter To: Kingsley Idehen , "webfinger@ietf.org" Date: Thu, 14 Feb 2013 14:25:10 +0100 Thread-Topic: [webfinger] Webfinger and RFC 6415 Thread-Index: Ac4Kr8jBYwhPzjGiRMiTOaEVOp3y2QABfuEg Message-ID: References: <5119AFC8.5070406@e14n.com> <511CDA0D.7060007@openlinksw.com> In-Reply-To: <511CDA0D.7060007@openlinksw.com> Accept-Language: en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [webfinger] R: Webfinger and RFC 6415 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, 14 Feb 2013 13:25:21 -0000 I would definitely sponsor mentioning this. Either as use case / example, o= r by creating a new section "Relationship with RFC6415 (Informational)" tha= t could illustrate this, and maybe add some statement about JRDs as well. In fact we will end up having JRD specified in 2 RFCs, and even if wire-com= patible (despite maybe the "expires" property...), some additional words co= uld be spent on this eg to state whether the wf jrd definition "obsoletes" = the rfc6145 one or otherwise how they relate. Another statement in that section could be on querying via wf for host-wide= information, that is instead of querying http://example.com/.well-known/host-meta.json query https://example.com/.well-known/webfinger?resource=3Dhttp://example.com as Paul already suggested quite a few times. finally, note that in your example the lrdd template url / wf endpoint is h= ttp whilst it should be https :) walter > -----Messaggio originale----- > Da: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] Per co= nto > di Kingsley Idehen > Inviato: gioved=EC 14 febbraio 2013 13.35 > A: webfinger@ietf.org > Oggetto: Re: [webfinger] Webfinger and RFC 6415 > > On 2/11/13 9:58 PM, Evan Prodromou wrote: > > If a server supports Web Host Metadata per RFC 6415, it can easily use > > the Webfinger endpoint as a JRD-serving LRDD link. You can make your > > /.well-known/host-meta.json (JRD-serving host-wide metadata) look > > something like this: > > > > { > > "links": [ > > { > > "rel": "lrdd", > > "type": "application/json", > > "template": > > "http://example.com/.well-known/webfinger?resource=3D{uri}" > > } > > ] > > } > > > > Supporting this usage was an important part of how we got to the > > current structure, but we don't mention it in the current draft. > > > > It can be documented elsewhere, but it might be useful in the document > > itself. Definitely not a blocker, but I wanted to bring it up. > > > > -Evan > > +1 > > We support this pattern in our servers. > > > -- > > Regards, > > Kingsley Idehen > Founder & CEO > OpenLink Software > Company Web: http://www.openlinksw.com > Personal Weblog: http://www.openlinksw.com/blog/~kidehen > Twitter/Identi.ca handle: @kidehen > Google+ Profile: https://plus.google.com/112399767740508618350/about > LinkedIn Profile: http://www.linkedin.com/in/kidehen > > > > 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 evan@status.net Fri Feb 15 06: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 4EF4321F8573 for ; Fri, 15 Feb 2013 06:00:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehDFiv9d1P2z for ; Fri, 15 Feb 2013 06:00:11 -0800 (PST) Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB5521F856D for ; Fri, 15 Feb 2013 06:00:11 -0800 (PST) Received: from [10.0.1.38] (modemcable064.24-130-66.mc.videotron.ca [66.130.24.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id 015B38D4662 for ; Fri, 15 Feb 2013 14:14:28 +0000 (UTC) Message-ID: <511E3F68.2060200@status.net> Date: Fri, 15 Feb 2013 09:00:08 -0500 From: Evan Prodromou User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: webfinger@ietf.org References: <5119AFC8.5070406@e14n.com> <511CDA0D.7060007@openlinksw.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [webfinger] R: Webfinger and RFC 6415 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, 15 Feb 2013 14:00:12 -0000 I think describing the relationship with RFC 6415 would be great. There's a subtle distinction between the host "example.com" and the specific resource "http://example.com/". I would expect to find information about SMTP and IMAP setup for the host, but it would be less reasonable for the URL. And, yes, the Webfinger endpoint should be https. Good eye! -Evan On 13-02-14 08:25 AM, Goix Laurent Walter wrote: > I would definitely sponsor mentioning this. Either as use case / example, or by creating a new section "Relationship with RFC6415 (Informational)" that could illustrate this, and maybe add some statement about JRDs as well. > > In fact we will end up having JRD specified in 2 RFCs, and even if wire-compatible (despite maybe the "expires" property...), some additional words could be spent on this eg to state whether the wf jrd definition "obsoletes" the rfc6145 one or otherwise how they relate. > > Another statement in that section could be on querying via wf for host-wide information, that is instead of querying > http://example.com/.well-known/host-meta.json > query > https://example.com/.well-known/webfinger?resource=http://example.com > as Paul already suggested quite a few times. > > finally, note that in your example the lrdd template url / wf endpoint is http whilst it should be https :) > > walter > >> -----Messaggio originale----- >> Da: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] Per conto >> di Kingsley Idehen >> Inviato: giovedì 14 febbraio 2013 13.35 >> A: webfinger@ietf.org >> Oggetto: Re: [webfinger] Webfinger and RFC 6415 >> >> On 2/11/13 9:58 PM, Evan Prodromou wrote: >>> If a server supports Web Host Metadata per RFC 6415, it can easily use >>> the Webfinger endpoint as a JRD-serving LRDD link. You can make your >>> /.well-known/host-meta.json (JRD-serving host-wide metadata) look >>> something like this: >>> >>> { >>> "links": [ >>> { >>> "rel": "lrdd", >>> "type": "application/json", >>> "template": >>> "http://example.com/.well-known/webfinger?resource={uri}" >>> } >>> ] >>> } >>> >>> Supporting this usage was an important part of how we got to the >>> current structure, but we don't mention it in the current draft. >>> >>> It can be documented elsewhere, but it might be useful in the document >>> itself. Definitely not a blocker, but I wanted to bring it up. >>> >>> -Evan >> +1 >> >> We support this pattern in our servers. >> >> >> -- >> >> Regards, >> >> Kingsley Idehen >> Founder & CEO >> OpenLink Software >> Company Web: http://www.openlinksw.com >> Personal Weblog: http://www.openlinksw.com/blog/~kidehen >> Twitter/Identi.ca handle: @kidehen >> Google+ Profile: https://plus.google.com/112399767740508618350/about >> LinkedIn Profile: http://www.linkedin.com/in/kidehen >> >> >> >> > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. > > This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger From paulej@packetizer.com Mon Feb 18 14:56:19 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 E882E21E804E for ; Mon, 18 Feb 2013 14:56:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ximD8qgi3gA for ; Mon, 18 Feb 2013 14:56:17 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id A1E1F21E8054 for ; Mon, 18 Feb 2013 14:56:16 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r1IMuEFN010647 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 18 Feb 2013 17:56:15 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1361228175; bh=tEQ773ItYLieB2bxKkgozK0rTPfdofqrQnurlYJkBys=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=VkR2eAqvQ8Hri8wMzEOgBa9baIhO+xdLYTMyXd2KHRDp6LYhqaGk5W5Gfv3VR+A5k lJaUlBA33IZ2dwXxGhQdwLiEYKhPkrgSS0kYSvJiRnHAf7k7UMoZm7tBOJe/Y73tBW qVKcbDiegeZnWWBsGKkblFyxOaYRVXK5HsAlHBC8= From: "Paul E. Jones" To: "'Evan Prodromou'" , References: <5119AFC8.5070406@e14n.com> <511CDA0D.7060007@openlinksw.com> <511E3F68.2060200@status.net> In-Reply-To: <511E3F68.2060200@status.net> Date: Mon, 18 Feb 2013 17:56:18 -0500 Message-ID: <04dc01ce0e2b$29e83730$7db8a590$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGZszuII83mfDXGptnWC6VmcBNnaAMfR+6IApZGtwECbq0FCJinyF2g Content-Language: en-us Subject: Re: [webfinger] R: Webfinger and RFC 6415 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: Mon, 18 Feb 2013 22:56:19 -0000 Evan, et al, So, there is a proposal for a one-line comment and one for a more = expansive section. I have no strong preference. Would you or someone else like = to suggest exactly what they would like to see in the document? Paul > -----Original Message----- > From: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] = On > Behalf Of Evan Prodromou > Sent: Friday, February 15, 2013 9:00 AM > To: webfinger@ietf.org > Subject: Re: [webfinger] R: Webfinger and RFC 6415 >=20 > I think describing the relationship with RFC 6415 would be great. >=20 > There's a subtle distinction between the host "example.com" and the > specific resource "http://example.com/". >=20 > I would expect to find information about SMTP and IMAP setup for the > host, but it would be less reasonable for the URL. >=20 > And, yes, the Webfinger endpoint should be https. Good eye! >=20 > -Evan >=20 > On 13-02-14 08:25 AM, Goix Laurent Walter wrote: > > I would definitely sponsor mentioning this. Either as use case / > example, or by creating a new section "Relationship with RFC6415 > (Informational)" that could illustrate this, and maybe add some > statement about JRDs as well. > > > > In fact we will end up having JRD specified in 2 RFCs, and even if > wire-compatible (despite maybe the "expires" property...), some > additional words could be spent on this eg to state whether the wf jrd > definition "obsoletes" the rfc6145 one or otherwise how they relate. > > > > Another statement in that section could be on querying via wf for > > host-wide information, that is instead of querying > > http://example.com/.well-known/host-meta.json > > query > > = https://example.com/.well-known/webfinger?resource=3Dhttp://example.com > > as Paul already suggested quite a few times. > > > > finally, note that in your example the lrdd template url / wf = endpoint > > is http whilst it should be https :) > > > > walter > > > >> -----Messaggio originale----- > >> Da: webfinger-bounces@ietf.org [mailto:webfinger-bounces@ietf.org] > >> Per conto di Kingsley Idehen > >> Inviato: gioved=EC 14 febbraio 2013 13.35 > >> A: webfinger@ietf.org > >> Oggetto: Re: [webfinger] Webfinger and RFC 6415 > >> > >> On 2/11/13 9:58 PM, Evan Prodromou wrote: > >>> If a server supports Web Host Metadata per RFC 6415, it can easily > >>> use the Webfinger endpoint as a JRD-serving LRDD link. You can = make > >>> your /.well-known/host-meta.json (JRD-serving host-wide metadata) > >>> look something like this: > >>> > >>> { > >>> "links": [ > >>> { > >>> "rel": "lrdd", > >>> "type": "application/json", > >>> "template": > >>> "http://example.com/.well-known/webfinger?resource=3D{uri}" > >>> } > >>> ] > >>> } > >>> > >>> Supporting this usage was an important part of how we got to the > >>> current structure, but we don't mention it in the current draft. > >>> > >>> It can be documented elsewhere, but it might be useful in the > >>> document itself. Definitely not a blocker, but I wanted to bring = it > up. > >>> > >>> -Evan > >> +1 > >> > >> We support this pattern in our servers. > >> > >> > >> -- > >> > >> Regards, > >> > >> Kingsley Idehen > >> Founder & CEO > >> OpenLink Software > >> Company Web: http://www.openlinksw.com Personal Weblog: > >> http://www.openlinksw.com/blog/~kidehen > >> Twitter/Identi.ca handle: @kidehen > >> Google+ Profile: = https://plus.google.com/112399767740508618350/about > >> LinkedIn Profile: http://www.linkedin.com/in/kidehen > >> > >> > >> > >> > > > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente > alle persone indicate. La diffusione, copia o qualsiasi altra azione > derivante dalla conoscenza di queste informazioni sono rigorosamente > vietate. Qualora abbiate ricevuto questo documento per errore siete > cortesemente pregati di darne immediata comunicazione al mittente e di > provvedere alla sua distruzione, Grazie. > > > > This e-mail and any attachments is confidential and may contain > privileged information intended for the addressee(s) only. = Dissemination, > copying, printing or use by anybody else is unauthorised. If you are = not > the intended recipient, please delete this message and any attachments > and advise the sender by return e-mail, Thanks. > > > > _______________________________________________ > > webfinger mailing list > > webfinger@ietf.org > > https://www.ietf.org/mailman/listinfo/webfinger >=20 > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger From stpeter@stpeter.im Fri Feb 22 11:10:16 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 E697E21F8B46 for ; Fri, 22 Feb 2013 11:10:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AmLhVnAuoOPp for ; Fri, 22 Feb 2013 11:10:10 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id CA00321F87AA for ; Fri, 22 Feb 2013 11:10:10 -0800 (PST) Received: from [10.129.24.65] (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5D3C4403CD for ; Fri, 22 Feb 2013 12:17:45 -0700 (MST) Message-ID: <5127C28D.4090802@stpeter.im> Date: Fri, 22 Feb 2013 12:10:05 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: "webfinger@ietf.org" References: <5127BC9B.8000203@stpeter.im> In-Reply-To: <5127BC9B.8000203@stpeter.im> X-Enigmail-Version: 1.5 X-Forwarded-Message-Id: <5127BC9B.8000203@stpeter.im> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [webfinger] Fwd: [Aggsrv] updated charter proposal 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, 22 Feb 2013 19:10:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This might be of interest to folks here! - -------- Original Message -------- Subject: [Aggsrv] updated charter proposal Date: Fri, 22 Feb 2013 11:44:43 -0700 From: Peter Saint-Andre To: aggsrv@ietf.org The proponents have sent me an updated charter for the aggsrv initiative. The text can be found below, and I've also updated http://trac.tools.ietf.org/wg/appsawg/trac/wiki/AggSrv accordingly. ### Aggregated Service Discovery Working Group Problem Statement: Service providers and enterprises commonly offer a variety of application services delivered over multiple protocols. A user will often consume these services from several endpoints, requiring service discovery or manual configuration for each service at each endpoint. Some of these services leverage existing standards-based discovery, such as DNS, DHCP, or UDDI, while others may rely on some form of proprietary discovery. Still others may not support any form of discovery, requiring the manual entry of service access information. As the quantity and variety of these services grow, it becomes increasingly onerous for administrators to manage the disparate discovery mechanisms, and burdensome on users to provide configuration where discovery is not supported. It is useful to first consider whether the issues described here might be addressable through the direct use or extension of existing discovery protocols. DHCP [1], for example, is widely deployed and supports extension for the discovery of new types of services. Many DHCP extensions already exist for the discovery of such services as DNS, NTP, NIS, LDAP, and others. The DHCP protocol, however, is limited by a dependence on local network broadcast, lack of support for structured data, and an extension mechanism not intended for unregistered customization. This, coupled with a relative dearth of application-level APIs supporting DHCP service-specific extensions, makes DHCP an unlikely solution for the issues we face here. Another option would be to leverage DNS through DNS-SD [2]. The DNS-SD extension is expressly designed to support Internet-scale service discovery using standard DNS queries and existing record types. However, it remains a significant limitation that the discovered data is global and cannot be made a function of information provided in the request. For example, an enterprise with several IMAP servers, each servicing the same email domain but hosting different subsets of employees, could not employ DNS-SD for email service discovery using that one domain. It is also important to consider that we wish to establish a solution that is broadly and uniformly usable across a wide array of platforms and environments. It is an unfortunate fact that browser-based clients often lack the necessary APIs and trust necessary to make explicit DNS queries for particular types of records. In terms of new ideas, similar discovery standardization efforts already under way include WebFinger [3], which is intended to address generalized discovery for any type of URI identifiable resource, and Simple Web Discovery [4], which is more specifically related to the discovery of services. The former provides an interesting framework within which aggregated service discovery could operate, however by itself there is insufficient guidance and structure to address the specific needs of service discovery use cases. Simple Web Discovery, on the other hand, while expressly intended for the discovery of services, tends to focus specifically on service location and is not well suited for aggregate discovery of dissimilar service types. Objectives: The Aggregated Service Discovery working group will standardize an extensible protocol supporting the discovery of multiple services with a single operation and with limited initial information (e.g. a well-known URL, or email address). A central objective shall be the establishment of a protocol and message format which may be readily adopted by a wide variety of endpoints, minimizes client startup time by reducing network roundtrips, and takes into consideration the various technical challenges faced by clients in the wild, including security, firewalls, same-origin policies and limited platform APIs. Equally important, the working group will focus on ease of deployment, and support for both standard and non-standard services types. The barriers to adoption should be made as low as possible without compromising the security and integrity of the discovery process. In the interest of meeting the above objectives, this working group will develop a core message format based on JSON, and protocol based on HTTP and REST (using [5] as the starting point). Initially, the group will focus on a draft defining an extensible aggregated discovery document structure, and operations for discovery document retrieval. The group will not necessarily define new formats and protocols, and will consider existing technologies where possible. Potential follow up work may include an additional draft for defining a complimentary protocol for local area network service discovery. This draft would define a means by which aggregated discovery documents may be obtained by clients in a fully automated manner, possibly based on mDNS or DHCP. However, the group would need to recharter in order to add such a draft to its deliverables. Milestones: Jun 2013 - Accept protocol and format document as Working Group item Oct 2013 - Start Working Group Last Call on protocol and format document Dec 2013 - Submit protocol and format document to IESG References: [1] RFC 2131 - DHCP [2] RFC 6763 - DNS-SD [3] draft-ietf-appsawg-webfinger [4] draft-jones-simple-web-discovery [5] draft-daboo-aggregated-service-discovery ### Peter _______________________________________________ aggsrv mailing list aggsrv@ietf.org https://www.ietf.org/mailman/listinfo/aggsrv -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRJ8KMAAoJEOoGpJErxa2pIUYP/jIhfA5f8sgRLkjBObtBL3Io N6R4wERXkxLrkM4elYe4GEcyFPyAOJ41HlI1xMo9WTizYsvsDd8q1iqAOZhrf0F8 R58fCTqkuaRBEAbqk0Bq/cjvMggYfrUqUaH1KMeAra7BIsdZw2oTSrwTlfrhs5Ed LNJx801LK8Xo/D5u5jl2mQd18XKb8MhT9b38Z6xZpvvGmjPywRM4mUXqrJtXcDh4 INv8pHUOi0DYQ/RzT+RjwfWXWKIYwuPyeoHf0rCXKRSt+w+gq/ujztAPsDsg6SK+ M3ffo7O1k8AkYWpmDuXU+ikySeHkXLoEWHnkmUZ4acZbzyOtJaUYEJwuXfaeC0br yCSexusKADvU4VROKhRbLSoU4fMpf0IyvHE3I03SYkaASfVtHupEPkILsNhHV4dQ FZOg55X4wYCJAuJvEb5hRqkwJXuGz7cfiZw5x1FiEGNyfOF87dIbEZ6K7LbcFdfm ypizdd7wVOnrXoGwee46tQVxZVlMqsL/Yo9ZQQiN68vDcw0qrRx7XsHrRoJFIHuZ A4rADLbjeEl/tp2elTQeMwHevOM/6GS5zd8GWvk6FJx9ZH+9aK41W44YiCfH5RQU 0+alf5IFzoEZ1YTLLe0pGL9jNLJegcju9BsP6cP3k6lQpaYUoP0LMgMMM3GfMN04 sJsNFiU3149vK1XyLVGv =k1KJ -----END PGP SIGNATURE----- From paulej@packetizer.com Wed Feb 27 10:07:54 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 2E37221F88E8 for ; Wed, 27 Feb 2013 10:07:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.393 X-Spam-Level: X-Spam-Status: No, score=-2.393 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oiZJtX7htUO8 for ; Wed, 27 Feb 2013 10:07:53 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6D221F88E1 for ; Wed, 27 Feb 2013 10:07:53 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r1RI7p32014527 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Feb 2013 13:07:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1361988471; bh=MpUVxvEvMgui5ZPtHm5OoLOXRWFe52g1RnemQ2nvA9c=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; b=W9IlideyIRh7qHdtoh7ayTkZIxYeCeEvUnNaCsK67suAnP+ZhEgDCng43/ZIVbU1H kc9ktIc/1/RnNdLZrkipG59WUDXUEPeCVlqU1Xbx7Nb1qZwfi5gH1KwRdY6lgdShmt 55F6YlvgIuxcv9U7S4gFX8/AXEP5bjBcWtoMiygY= From: "Paul E. Jones" To: , Date: Wed, 27 Feb 2013 13:07:58 -0500 Message-ID: <00f101ce1515$60213a90$2063afb0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F2_01CE14EB.774B80B0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4VFQ85OKxTQpORR72DrP54Def8zg== Content-Language: en-us Subject: [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: Wed, 27 Feb 2013 18:07:54 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00F2_01CE14EB.774B80B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Folks, I decided to start maintaining a list of client and server software: http://www.packetizer.com/webfinger/software.html I'll maintain this page until such time as it becomes a burden, but I think it would be useful for a while as WebFinger is still very young. If you have an implementation you'd like to have listed here, please provide me with the info required to fully populate the table. Paul ------=_NextPart_000_00F2_01CE14EB.774B80B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

I decided to = start maintaining a list of client and server software:

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

 

I’ll = maintain this page until such time as it becomes a burden, but I think = it would be useful for a while as WebFinger is still very = young.

 

If you have an implementation you’d like to have = listed here, please provide me with the info required to fully populate = the table.

 

Paul

 

------=_NextPart_000_00F2_01CE14EB.774B80B0-- From kidehen@openlinksw.com Wed Feb 27 12:58:08 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 B1AA421F886D for ; Wed, 27 Feb 2013 12:58:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mi3n6CG+xh0V for ; Wed, 27 Feb 2013 12:58:07 -0800 (PST) Received: from mail.openlinksw.com (mail.openlinksw.com [63.119.36.38]) by ietfa.amsl.com (Postfix) with ESMTP id C54DA21F8860 for ; Wed, 27 Feb 2013 12:58:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=openlinksw.com; s=x; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=ybHzR/mkrp1TEEGGcRwT5IuAf3ioiyCmCvcUmg6vt8s=; b=Wc5lMfMaNgJce/+J0gmL/P51xzepTXTErK8EuphVa/dn3wCpxa/PPONXNRWgTxA7eFCxJ48S8FMzveqBblleyPpczJIqPlg6ERS+1TU9F4/JL4XKRQtySDdQXWiR/iHn; Received: from kidehen.vpn ([10.100.2.3] helo=Macintosh-96.local) by mail.openlinksw.com with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.74) (envelope-from ) id 1UAo4i-0006iJ-Vv; Wed, 27 Feb 2013 15:58:05 -0500 Message-ID: <512E735C.3010109@openlinksw.com> Date: Wed, 27 Feb 2013 15:58:04 -0500 From: Kingsley Idehen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Paul E. Jones" References: <00f101ce1515$60213a90$2063afb0$@packetizer.com> In-Reply-To: <00f101ce1515$60213a90$2063afb0$@packetizer.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090508070309040204090904" Cc: webfinger@ietf.org, webfinger@googlegroups.com 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: Wed, 27 Feb 2013 20:58:08 -0000 This is a cryptographically signed message in MIME format. --------------ms090508070309040204090904 Content-Type: multipart/alternative; boundary="------------020206080307090104020309" This is a multi-part message in MIME format. --------------020206080307090104020309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 2/27/13 1:07 PM, Paul E. Jones wrote: > > Folks, > > I decided to start maintaining a list of client and server software: > > http://www.packetizer.com/webfinger/software.html > > I'll maintain this page until such time as it becomes a burden, but I=20 > think it would be useful for a while as WebFinger is still very young. > > If you have an implementation you'd like to have listed here, please=20 > provide me with the info required to fully populate the table. > > Paul > > > > _______________________________________________ > webfinger mailing list > webfinger@ietf.org > https://www.ietf.org/mailman/listinfo/webfinger Paul, Note: 1. https://delicious.com/kidehen/webfinger . 2. https://delicious.com/kidehen/webfinger_demo . 3. http://web.ods.openlinksw.com -- supports Webfinger . 4. http://virtuoso.openlinksw.com -- supports Webfinger . --=20 Regards, Kingsley Idehen=09 Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca handle: @kidehen Google+ Profile: https://plus.google.com/112399767740508618350/about LinkedIn Profile: http://www.linkedin.com/in/kidehen --------------020206080307090104020309 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On 2/27/13 1:07 PM, Paul E. Jones wrote:

Folks,

 

I decided to start maintaining a list of client and server software:

ht= tp://www.packetizer.com/webfinger/software.html

 

I’ll maintain this page until such t= ime as it becomes a burden, but I think it would be useful for a while as WebFinger is still very young.

 

If you have an implementation you’d = like to have listed here, please provide me with the info required to fully populate the table.

 

Paul

 



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

Note:

1. https://delicious.com/kidehen/webfinger .
2. https://delicious.com/kidehen/webfinger_demo .=
3. http://web.ods.openlinksw.com -- supports Webfinger .
4. http://virtuoso.openlinksw.com -- supports Webfinger . 

--=20

Regards,

Kingsley Idehen	     =20
Founder & CEO=20
OpenLink Software    =20
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767=
740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
--------------020206080307090104020309-- --------------ms090508070309040204090904 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIID8zCC A+8wggLXoAMCAQICAgSPMA0GCSqGSIb3DQEBBQUAMEExIzAhBgNVBAMMGk9wZW5MaW5rIFNv ZnR3YXJlIExvY2FsIENBMRowGAYDVQQKDBFPcGVuTGluayBTb2Z0d2FyZTAeFw0xMzAyMjMy MTUwNThaFw0xNDAyMjMyMTUwNThaMGExHDAaBgNVBAMTE0tpbmdzbGV5IFV5aSBJZGVoZW4x GjAYBgNVBAoTEU9wZW5MaW5rIFNvZnR3YXJlMSUwIwYJKoZIhvcNAQkBFhZraWRlaGVuQG9w ZW5saW5rc3cuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAun8PsZGCJvxI +x+Prt508na+aURR0ICKjsjwwhcPAhB7LSUMpPz/t3pHBxwBBDc/pCqqo5dSZxncZvZ+bC3Z sZHYg04LOLMaVje8AUDB74A723qC8EWn2UNxUwhB6PK1zX4bteKYQaViwNXYRYO+2G57KaAT 7YE9k27n40CGxz58jpCCgmMcFF53TPn76qGmwrgIlHcbQoKUxNr2Dr4Aga4K6SH4Kke3ZL+N FalfDXHFWncvq0Z0Yhdb99fgM4qtSkfSgwo0E305qSYtNvglyrSaaUj2ZQrX0WAaqMu63U+c WjwWAOM1aR/xTVxHEUlKQt++hvI0yPOxyvdymvAO/QIDAQABo4HQMIHNMB0GA1UdDgQWBBR1 zbKhTzGVLkkicoo5UU3IOuIZWDBLBgNVHREERDBChkBodHRwOi8vaWQubXlvcGVubGluay5u ZXQvZGF0YXNwYWNlL3BlcnNvbi9LaW5nc2xleVV5aUlkZWhlbiN0aGlzMC0GCWCGSAGG+EIB DQQgFh5WaXJ0dW9zbyBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwDgYDVR0PAQH/BAQDAgWgMCAG A1UdJQEB/wQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAQEAprvJ MPqaBszcJp0XN7FooVQDbaUjWIQIBynHY8ezwJdsh+r5tHXvxdWOnf4c4MhtPVtxNHESy2pG r9Y3uv/JKL+wQZ6rP25x70pJzrHYFZbsMbkUzLQ4bkzd7QRyKlhyty87f2r5LRqQ0fLtsA2v dejaEUT0OSuRr2KfKXu/l6c/+FmxSWtvGMPKLkjok44kS4w+B2eyQWthaemj1g8vLPM3Lvsg kWzWVAMdP+vmOaa6bqOYuIkfqTHLh0uhGuoWYCMOcBUI1MnwMN6WCysn0y4J2yUsfs375v8w do1AgQHg5QEVEwLrYDRh/1EZzjrDWhWURE+etB8rm8TBYSx6NzGCAu8wggLrAgEBMEcwQTEj MCEGA1UEAwwaT3BlbkxpbmsgU29mdHdhcmUgTG9jYWwgQ0ExGjAYBgNVBAoMEU9wZW5MaW5r IFNvZnR3YXJlAgIEjzAJBgUrDgMCGgUAoIIBfTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xMzAyMjcyMDU4MDRaMCMGCSqGSIb3DQEJBDEWBBTfv5gok+LB AksoWt/OqnpvGIfR9zBWBgkrBgEEAYI3EAQxSTBHMEExIzAhBgNVBAMMGk9wZW5MaW5rIFNv ZnR3YXJlIExvY2FsIENBMRowGAYDVQQKDBFPcGVuTGluayBTb2Z0d2FyZQICBI8wWAYLKoZI hvcNAQkQAgsxSaBHMEExIzAhBgNVBAMMGk9wZW5MaW5rIFNvZnR3YXJlIExvY2FsIENBMRow GAYDVQQKDBFPcGVuTGluayBTb2Z0d2FyZQICBI8wbAYJKoZIhvcNAQkPMV8wXTALBglghkgB ZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG 9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQCU1EV0 o+GcKJ1jVbvnPLF05k+bx6TRvRqyWBmC71sn8ENJp8+1V1pHIjjLSMAmFLqjmcGD+YHNPBaf X6PLwPADLkbLnfsI+cAhVvTtHTD6USgJ3LBnkrVB5uN+Jm4hmr+lVZo2vT/4JWRYDBmJ6Vie oDqeb/qCI9y9USonk/w93ZmJpGeYq2hrOaVOs0QMqUjTpYV8xjy3JExuEybC5muGlxcCCQFm 3QVkpEJlaGQ3fVVS5qOBMY8zizX3/XfrjvkrShUJqBsXmQ6I4sHDnrYN5re4AHzLT4SoYq5V p6BtQZeYiu6i4+djmmvqmqrYcgmerMzJLrhRP9T1FdwSfQ1FAAAAAAAA --------------ms090508070309040204090904--


On Thu, Feb 7, 2013 at 12:35 PM, Brad Fitzpatrick <brad= fitz@google.com> wrote:
I'd be happy seeing it = removed.

HTTP seems sufficient.



On Thu, Feb 7, 2013 at 12:28 PM, Paul E. Jones = <paulej@packe= tizer.com> wrote:

Folks= ,

=A0

Questions have been raised about the =93expires=94 m= ember of the JRD two or three times now, with concerns related to the fact = that HTTP has multiple ways of also indicating how long a resource represen= tation should be cached.

=A0

This ele= ment is exists for historical reason, but it=92s not clear to me if anyone = is using it or cares to use it.

= =A0

Shall we keep it or just remove it from the spec ent= irely?

<= font color=3D"#888888">

=A0

Paul

= =A0

=

--
=A0
---
You received this message because you are subscribed to the Google Groups &= quot;WebFinger" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to webfinger+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
=A0
=A0


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