From nobody Mon Aug 11 19:29:20 2014 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACCFD1A0119 for ; Mon, 11 Aug 2014 19:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.041 X-Spam-Level: * X-Spam-Status: No, score=1.041 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id slKr0QyACjZt for ; Mon, 11 Aug 2014 19:29:16 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64AF11A010E for ; Mon, 11 Aug 2014 19:29:16 -0700 (PDT) Received: from [192.168.1.20] (cpe-024-211-197-136.nc.res.rr.com [24.211.197.136]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id s7C2TEA5027145 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 11 Aug 2014 22:29:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1407810554; bh=HAgRS9b1Q/MSx1f1fS0vJZ67VJhCf9XJ2QwZhrWD85M=; h=From:To:Subject:Date:Message-Id:Reply-To:Mime-Version: Content-Type; b=YssG6olTWqYq6mpwFhh7Z6zWN+T+6xds+VusmGZmHq3unFKuTI0WAcEZOG7mp6TGL k1ORQheZ1XlxH4kyqZjsJIz+y93Px9ImIjchfeGHxKoXaCEF163/le1Vw9Dv7j7VJA rHq5WqTPpKyu5cp5MTu5WuPjDrtOeAdXpZ1yhDgw= From: "Paul E. Jones" To: webfinger@ietf.org, "webfinger@googlegroups.com" Date: Tue, 12 Aug 2014 02:29:33 +0000 Message-Id: User-Agent: eM_Client/6.0.20617.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MB7F05519F-1C09-4963-ABC3-CFC939846269" Archived-At: http://mailarchive.ietf.org/arch/msg/webfinger/PycpHVflEX-ZJ6KL6opANGliMlA Subject: [webfinger] Redefining "properties" X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Paul E. Jones" 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 Aug 2014 02:29:18 -0000 --------=_MB7F05519F-1C09-4963-ABC3-CFC939846269 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Folks, I have been asked by multiple people for different purposes to see if it= =20 might be possible to redefine "properties" in the JSON Resource=20 Descriptor. Per RFC 7033, "properties" is defined as an object that has zero or more= =20 name/value pairs whose values are strings or null. The suggestion is=20 that the values should be any valid JSON type. Thus, a property might=20 refer to a string (as is does now) or it might refer to an object or=20 array. This change would break any parsers strictly implement definition of=20 "properties". So, there are two questions I want to present to those=20 who are interested: 1) Would you be agreeable to change the current definition of=20 "properties" to allow any value type? 2) If not, would be agreeable to introducing something like "properties"= =20 that essentially allows for the same and, if so, what should this new=20 object be named? Personally, as much as I don't like breaking backward-compatibility, I'm= =20 favorable to redefining properties to accomodate what people want to do.= =20 I'm willing to work on an RFC 7033bis and/or a new RFC to update the=20 JRD specification, if folks are agreeable to either (1) or (2). Paul --------=_MB7F05519F-1C09-4963-ABC3-CFC939846269 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Folks,
 
I have been asked by multiple people for different purposes to see = if it might be possible to redefine "properties" in the JSON Resource Descr= iptor.
 
Per RFC 7033, "properties" is defined as an object that has zero or= more name/value pairs whose values are strings or null.  The suggesti= on is that the values should be any valid JSON type.  Thus, a property= might refer to a string (as is does now) or it might refer to an object= or array.
 
This change would break any parsers strictly implement definition of= "properties".  So, there are two questions I want to present = to those who are interested:
 
1) Would you be agreeable to change the current definition of "propert= ies" to allow any value type?
2) If not, would be agreeable to introducing something like "propertie= s" that essentially allows for the same and, if so, what should this new= object be named?
 
Personally, as much as I don't like breaking backward-compatibility,= I'm favorable to redefining properties to accomodate what people want to= do.  I'm willing to work on an RFC 7033bis and/or a new RFC to update= the JRD specification, if folks are agreeable to either (1) or (2).
 
Paul
 
--------=_MB7F05519F-1C09-4963-ABC3-CFC939846269-- From nobody Mon Aug 11 20:40:04 2014 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D30B1A01CA for ; Mon, 11 Aug 2014 20:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.423 X-Spam-Level: * X-Spam-Status: No, score=1.423 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i474U838zuUO for ; Mon, 11 Aug 2014 20:40:01 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 611321A01C3 for ; Mon, 11 Aug 2014 20:40:01 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id z11so6679412lbi.3 for ; Mon, 11 Aug 2014 20:39:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=fLEkPHfaElAKKVcrJCdxYvcSuaHhrWei1xzda+HHc+o=; b=ypVgS9bxnCtByd34Ar7e94muX1p2r/DopAx0NSPnwQPmeKZu8HDOZT7BhbFhxKkgrj dw5VzGCmw0rH8YM8dmOM4mOrQfDbSrbZa57QpK9MQ6+kJh0qwoZfnG0+5GaX2qiWe5eF TaVcgcL6BQoaHur95xKSwM1BMMKwBQwkGLlnhoPvZkauguEI03XKTruTR6FbVjGO5k7t OkfwRaRW3P3UJ5Q7bcndVUMly34xoIZNFfrCS3Ehsp76aVStGzZUTMjTEdonAoV4UXEB xvk/E0DDbLcGoN+u2uKtexhPLJMlScCezOJbcEtKNuj1zrjrHNNyKrJedJs6ZshRDPvz t7rQ== X-Received: by 10.152.243.43 with SMTP id wv11mr1575479lac.52.1407814799557; Mon, 11 Aug 2014 20:39:59 -0700 (PDT) MIME-Version: 1.0 Sender: wnorris@gmail.com Received: by 10.152.124.200 with HTTP; Mon, 11 Aug 2014 20:39:19 -0700 (PDT) In-Reply-To: References: From: Will Norris Date: Mon, 11 Aug 2014 20:39:19 -0700 X-Google-Sender-Auth: Lol8-hYUWGSjKDgHn_D8Vmx2U1E Message-ID: To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=001a113433ae098d1e0500666d5f Archived-At: http://mailarchive.ietf.org/arch/msg/webfinger/XzqvAvPTUj817ngwu7fFDAi18DM Cc: "webfinger@ietf.org" Subject: Re: [webfinger] Redefining "properties" X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.15 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 Aug 2014 03:40:03 -0000 --001a113433ae098d1e0500666d5f Content-Type: text/plain; charset=UTF-8 what are the actual use cases prompting this? If folks are trying to store more complicated data, why is it not just a linked resource? Personally, as a client author, I've always hated it when APIs have polymorphic data types like this. On Mon, Aug 11, 2014 at 7:29 PM, 'Paul E. Jones' via WebFinger < webfinger@googlegroups.com> wrote: > Folks, > > I have been asked by multiple people for different purposes to see if it > might be possible to redefine "properties" in the JSON Resource Descriptor. > > Per RFC 7033, "properties" is defined as an object that has zero or more > name/value pairs whose values are strings or null. The suggestion is that > the values should be any valid JSON type. Thus, a property might refer to > a string (as is does now) or it might refer to an object or array. > > This change would break any parsers strictly implement definition of > "properties". So, there are two questions I want to present to those who > are interested: > > 1) Would you be agreeable to change the current definition of > "properties" to allow any value type? > 2) If not, would be agreeable to introducing something like "properties" > that essentially allows for the same and, if so, what should this new > object be named? > > Personally, as much as I don't like breaking backward-compatibility, I'm > favorable to redefining properties to accomodate what people want to do. > I'm willing to work on an RFC 7033bis and/or a new RFC to update the JRD > specification, if folks are agreeable to either (1) or (2). > > 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/d/optout. > --001a113433ae098d1e0500666d5f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
what are the actual use cases prompting this? =C2=A0If fol= ks are trying to store more complicated data, why is it not just a linked r= esource?

Personally, as a client author, I've always= hated it when APIs have polymorphic data types like this.


On Mon,= Aug 11, 2014 at 7:29 PM, 'Paul E. Jones' via WebFinger <webfinger@googlegroups.com> wrote:
Folks,
=C2=A0
I have been asked by multiple people for different purposes to see if = it might be possible to redefine "properties" in the JSON Resourc= e Descriptor.
=C2=A0
Per RFC 7033, "properties" is defined as an object that has = zero or more name/value pairs whose values are strings or null.=C2=A0 The s= uggestion is that the values should be any valid JSON type.=C2=A0 Thus, a p= roperty might refer to a string (as is does now) or it might refer to an ob= ject or array.
=C2=A0
This change would break any parsers strictly implement definition of &= quot;properties".=C2=A0 So, there are=C2=A0two questions I want to pre= sent to those who are interested:
=C2=A0
1) Would you be agreeable to change the current definition of "pr= operties"=C2=A0to allow any value type?
2) If not, would be agreeable to introducing something like "prop= erties" that essentially allows for the same and, if so, what should t= his new object be named?
=C2=A0
Personally, as much as I don't like breaking backward-compatibilit= y, I'm favorable to redefining properties to accomodate what people wan= t to do.=C2=A0 I'm willing to work on an RFC 7033bis and/or a new RFC t= o update the JRD specification, if folks are agreeable to either (1) or (2)= .
=C2=A0
Paul
=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/d/optout.

--001a113433ae098d1e0500666d5f-- From nobody Sat Aug 16 12:05:36 2014 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7076B1A015F for ; Sat, 16 Aug 2014 12:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.031 X-Spam-Level: X-Spam-Status: No, score=0.031 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCuvxTj7iboD for ; Sat, 16 Aug 2014 12:05:31 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 162281A015D for ; Sat, 16 Aug 2014 12:05:30 -0700 (PDT) Received: from [192.168.1.20] (cpe-024-211-197-136.nc.res.rr.com [24.211.197.136]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id s7GJ5Sn8013786 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 16 Aug 2014 15:05:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1408215929; bh=z8BmAOT/A9k5vgzUln4BMVrHyIHr9oQYwAgYFqOvRz8=; h=From:To:Subject:Cc:Date:Message-Id:In-Reply-To:Reply-To: Mime-Version:Content-Type; b=Th4iwE9RQqtbW6JUKOTi2MWHtXrUFuhrc4KUrhpOUuxm03TUMyvL1OZsSJ2tJgwPJ 1vrvxSrE8OYeNaFmhzX+9lcAAKpRY2hFqKeOwrl8SRONLBwiQ54yhcxwi91CGG9nBs GYH6Dx7Q6acrUquSEeffkd5xCwLwaNcVvby8ktrE= From: "Paul E. Jones" To: "Will Norris" , webfinger@googlegroups.com Date: Sat, 16 Aug 2014 19:05:45 +0000 Message-Id: In-Reply-To: User-Agent: eM_Client/6.0.20617.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MBE67A788A-E95F-4D45-A935-D85BB39D8337" Archived-At: http://mailarchive.ietf.org/arch/msg/webfinger/je7hCvauSVK2IpClqgSgUtbDwjQ Cc: "webfinger@ietf.org" Subject: Re: [webfinger] Redefining "properties" X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Paul E. Jones" 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, 16 Aug 2014 19:05:34 -0000 --------=_MBE67A788A-E95F-4D45-A935-D85BB39D8337 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Will, Sorry for the slow response. I've been busy. Yes, folks do want to put more complex data into JRD as opposed to=20 linking, including objects or arrays. I can see how this can be abused,= =20 but then I can also see an argument for not linking to data that could=20 be trivially represented inside the JRD itself. Unfortunately, I do not have details of the specific use cases. All I=20 do know is that there people working on unrelated applications where=20 they want to be able to do things like this with WebFinger: "properties" : { "http://example.com/ns/foo" : { "a" : "Hello", "b" : 32 } } Perhaps what might be worse is the possibility that people do this: ... "properties" : { "http://example.com/ns/foo" : "{\"a\" : \"Hello\", \"b\" : 32}" } ... When working on WebFinger, there was a desire to keep it as simple as=20 possible. However, I fully appreciate why some would want to do=20 something like this. Sometimes, linking to external resources is=20 "overkill" for the task at hand. And, you're right that dealing with=20 polymorphic data types can be a pain. Then again, the JSON parser deals= =20 with much of this automatically and the client is likely going to only=20 be looking for known members, anyway. So, I'm not sure what to do here. I'm OK with making a change. It=20 bothers me that we might break any client code that assumes all=20 properties are strings. But, there is always the option to add some=20 other member named something other than "properties". I take it you're not too keen on the idea, though. Paul ------ Original Message ------ From: "Will Norris" To: webfinger@googlegroups.com Cc: "webfinger@ietf.org" Sent: 8/11/2014 11:39:19 PM Subject: Re: [webfinger] Redefining "properties" >what are the actual use cases prompting this? If folks are trying to=20 >store more complicated data, why is it not just a linked resource? > >Personally, as a client author, I've always hated it when APIs have=20 >polymorphic data types like this. > > >On Mon, Aug 11, 2014 at 7:29 PM, 'Paul E. Jones' via WebFinger=20 > wrote: >>Folks, >> >>I have been asked by multiple people for different purposes to see if=20 >>it might be possible to redefine "properties" in the JSON Resource=20 >>Descriptor. >> >>Per RFC 7033, "properties" is defined as an object that has zero or=20 >>more name/value pairs whose values are strings or null. The=20 >>suggestion is that the values should be any valid JSON type. Thus, a=20 >>property might refer to a string (as is does now) or it might refer to= =20 >>an object or array. >> >>This change would break any parsers strictly implement definition of=20 >>"properties". So, there are two questions I want to present to those=20 >>who are interested: >> >>1) Would you be agreeable to change the current definition of=20 >>"properties" to allow any value type? >>2) If not, would be agreeable to introducing something like=20 >>"properties" that essentially allows for the same and, if so, what=20 >>should this new object be named? >> >>Personally, as much as I don't like breaking backward-compatibility,=20 >>I'm favorable to redefining properties to accomodate what people want=20 >>to do. I'm willing to work on an RFC 7033bis and/or a new RFC to=20 >>update the JRD specification, if folks are agreeable to either (1) or=20 >>(2). >> >>Paul >> >> >>-- >> >>--- >>You received this message because you are subscribed to the Google=20 >>Groups "WebFinger" group. >>To unsubscribe from this group and stop receiving emails from it, send= =20 >>an email to webfinger+unsubscribe@googlegroups.com. >>For more options, visit https://groups.google.com/d/optout. > --------=_MBE67A788A-E95F-4D45-A935-D85BB39D8337 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Will,
 
Sorry for the slow response.  I've been busy.
 
Yes, folks do want to put more complex data into JRD as oppo= sed to linking, including objects or arrays.  I can see how this can= be abused, but then I can also see an argument for not linking to data = that could be trivially represented inside the JRD itself.
 
Unfortunately, I do not have details of the specific use cases. = All I do know is that there people working on unrelated applications where= they want to be able to  do things like this with WebFinger:
 
"properties" :
{
  "http://example.com/ns/foo" :
  {
    "a" : "Hello",
  &= nbsp; "b" : 32
  }
}
 
Perhaps what might be worse is the possibility that people do this:
 
...
"properties" :
{
&nbs= p; "http://example.com/ns/foo" : "{\"a\" : \"Hello\", \"b\" : 32}"
}
...
When working on WebFinger, there was a desire to keep it as simple = as possible.  However, I fully appreciate why some would want to do= something like this.  Sometimes, linking to external resources is = "overkill" for the task at hand.  And, you're right that dealing with= polymorphic data types can be a pain.  Then again, the JSON parser= deals with much of this automatically and the client is likely going to= only be looking for known members, anyway.
 
So, I'm not sure what to do here.  I'm OK with making a change.&n= bsp; It bothers me that we might break any client code that assumes all = properties are strings.  But, there is always the option to add some= other member named something other than "properties".
 
I take it you're not too keen on the idea, though.
 
Paul
 
------ Original Message ------
From: "Will Norris" <will@wi= llnorris.com>
Cc: "webfinger@ietf.org" <web= finger@ietf.org>
Sent: 8/11/2014 11:39:19 PM
Subject: Re: [webfinger] Redefining "properties"
 
what are the actual use cases prompting this?  If folks= are trying to store more complicated data, why is it not just a linked = resource?=20

Personally, as a client author, I've always hated it when APIs have= polymorphic data types like this.


On Mon, Aug 11, 2014 at 7:29 PM, 'Paul E. Jones'= via WebFinger <webfinger@googlegroups.com> wrote:
Folks,
 
I have been asked by multiple people for different purposes to see = if it might be possible to redefine "properties" in the JSON Resource Descr= iptor.
 
Per RFC 7033, "properties" is defined as an object that has zero or= more name/value pairs whose values are strings or null.  The suggesti= on is that the values should be any valid JSON type.  Thus, a property= might refer to a string (as is does now) or it might refer to an object= or array.
 
This change would break any parsers strictly implement definition of= "properties".  So, there are two questions I want to present = to those who are interested:
 
1) Would you be agreeable to change the current definition of "propert= ies" to allow any value type?
2) If not, would be agreeable to introducing something like "propertie= s" that essentially allows for the same and, if so, what should this new= object be named?
 
Personally, as much as I don't like breaking backward-compatibility,= I'm favorable to redefining properties to accomodate what people want to= do.  I'm willing to work on an RFC 7033bis and/or a new RFC to update= the JRD specification, if folks are agreeable to either (1) or (2).
<= SPAN class=3DHOEnZb>
 
Paul
 

--

---
You received this message because you are subscri= bed 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/d/optout.

--------=_MBE67A788A-E95F-4D45-A935-D85BB39D8337-- From nobody Sat Aug 16 12:21:58 2014 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5611A016C for ; Sat, 16 Aug 2014 12:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jcN67l1gSoap for ; Sat, 16 Aug 2014 12:21:55 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0181.outbound.protection.outlook.com [207.46.163.181]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8BE21A016B for ; Sat, 16 Aug 2014 12:21:54 -0700 (PDT) Received: from BN3PR0301CA0082.namprd03.prod.outlook.com (25.160.152.178) by BN1PR03MB188.namprd03.prod.outlook.com (10.255.200.151) with Microsoft SMTP Server (TLS) id 15.0.1005.10; Sat, 16 Aug 2014 19:21:51 +0000 Received: from BN1BFFO11FD052.protection.gbl (2a01:111:f400:7c10::1:170) by BN3PR0301CA0082.outlook.office365.com (2a01:111:e400:401e::50) with Microsoft SMTP Server (TLS) id 15.0.1010.18 via Frontend Transport; Sat, 16 Aug 2014 19:21:51 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1BFFO11FD052.mail.protection.outlook.com (10.58.145.7) with Microsoft SMTP Server (TLS) id 15.0.1010.11 via Frontend Transport; Sat, 16 Aug 2014 19:21:51 +0000 Received: from TK5EX14MBXC293.redmond.corp.microsoft.com ([169.254.2.111]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.03.0195.002; Sat, 16 Aug 2014 19:21:26 +0000 From: Mike Jones To: "Paul E. Jones" , Will Norris , "webfinger@googlegroups.com" Thread-Topic: [webfinger] Redefining "properties" Thread-Index: AQHPtdU6hil2+M2G6kyYHw6GiMhwPJvMUlSAgAdMK4CAAARhmw== Date: Sat, 16 Aug 2014 19:21:25 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439AE1FE1E@TK5EX14MBXC293.redmond.corp.microsoft.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439AE1FE1ETK5EX14MBXC293r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019005)(438002)(479174003)(24454002)(13464003)(377454003)(189002)(199003)(77096002)(50986999)(92726001)(79102001)(97736001)(19617315012)(33656002)(76176999)(87936001)(20776003)(2656002)(15202345003)(92566001)(19625215002)(19580405001)(19580395003)(86612001)(83322001)(80022001)(26826002)(77982001)(104016003)(19273905006)(85852003)(44976005)(6806004)(76482001)(15395725005)(55846006)(85306004)(106116001)(99396002)(69596002)(81342001)(107046002)(68736004)(84676001)(4396001)(81156004)(81542001)(64706001)(83072002)(16236675004)(54356999)(106466001)(74502001)(14971765001)(15975445006)(46102001)(86362001)(31966008)(84326002)(21056001)(95666004)(71186001)(74662001)(2501001)(563064011)(19607625011); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR03MB188; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0305463112 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/webfinger/-dwppgqedxBL1uBWdwwQTF0gScg Cc: "webfinger@ietf.org" Subject: Re: [webfinger] Redefining "properties" X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.15 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, 16 Aug 2014 19:21:57 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439AE1FE1ETK5EX14MBXC293r_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable People want to put JWK Sets into the results. ________________________________ From: Paul E. Jones Sent: =FD8/=FD16/=FD2014 12:05 PM To: Will Norris; webfinger@googlegroups.com Cc: webfinger@ietf.org Subject: Re: [webfinger] Redefining "properties" Will, Sorry for the slow response. I've been busy. Yes, folks do want to put more complex data into JRD as opposed to linking,= including objects or arrays. I can see how this can be abused, but then I= can also see an argument for not linking to data that could be trivially r= epresented inside the JRD itself. Unfortunately, I do not have details of the specific use cases. All I do k= now is that there people working on unrelated applications where they want = to be able to do things like this with WebFinger: "properties" : { "http://example.com/ns/foo" : { "a" : "Hello", "b" : 32 } } Perhaps what might be worse is the possibility that people do this: ... "properties" : { "http://example.com/ns/foo" : "{\"a\" : \"Hello\", \"b\" : 32}" } ... When working on WebFinger, there was a desire to keep it as simple as possi= ble. However, I fully appreciate why some would want to do something like = this. Sometimes, linking to external resources is "overkill" for the task = at hand. And, you're right that dealing with polymorphic data types can be= a pain. Then again, the JSON parser deals with much of this automatically= and the client is likely going to only be looking for known members, anywa= y. So, I'm not sure what to do here. I'm OK with making a change. It bothers= me that we might break any client code that assumes all properties are str= ings. But, there is always the option to add some other member named somet= hing other than "properties". I take it you're not too keen on the idea, though. Paul ------ Original Message ------ From: "Will Norris" > To: webfinger@googlegroups.com Cc: "webfinger@ietf.org" > Sent: 8/11/2014 11:39:19 PM Subject: Re: [webfinger] Redefining "properties" what are the actual use cases prompting this? If folks are trying to store= more complicated data, why is it not just a linked resource? Personally, as a client author, I've always hated it when APIs have polymor= phic data types like this. On Mon, Aug 11, 2014 at 7:29 PM, 'Paul E. Jones' via WebFinger > wrote: Folks, I have been asked by multiple people for different purposes to see if it mi= ght be possible to redefine "properties" in the JSON Resource Descriptor. Per RFC 7033, "properties" is defined as an object that has zero or more na= me/value pairs whose values are strings or null. The suggestion is that th= e values should be any valid JSON type. Thus, a property might refer to a = string (as is does now) or it might refer to an object or array. This change would break any parsers strictly implement definition of "prope= rties". So, there are two questions I want to present to those who are int= erested: 1) Would you be agreeable to change the current definition of "properties" = to allow any value type? 2) If not, would be agreeable to introducing something like "properties" th= at essentially allows for the same and, if so, what should this new object = be named? Personally, as much as I don't like breaking backward-compatibility, I'm fa= vorable to redefining properties to accomodate what people want to do. I'm= willing to work on an RFC 7033bis and/or a new RFC to update the JRD speci= fication, if folks are agreeable to either (1) or (2). 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/d/optout. --_000_4E1F6AAD24975D4BA5B16804296739439AE1FE1ETK5EX14MBXC293r_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
People want t= o put JWK Sets into the results.
From: Paul E. Jones
Sent: =FD8/= =FD16/=FD2014 12:05 PM
To: Will Norris; webfinger@googlegroups.com
Cc: webfinger@ietf.org
Subject: Re: [= webfinger] Redefining "properties"

Will,
 
Sorry for the slow response.  I've been busy.
 
Yes, folks do want to put more complex data into JRD as oppo= sed to linking, including objects or arrays.  I can see how this can b= e abused, but then I can also see an argument for not linking to data that = could be trivially represented inside the JRD itself.
 
Unfortunately, I do not have details of the specific use cases.  = All I do know is that there people working on unrelated applications where = they want to be able to  do things like this with WebFinger:
 
"properties" :
{
  "http://example.com/ns/foo" :
  {
    "a" : "Hello",
    "b" : 32
  }
}
 
Perhaps what might be worse is the possibility that people do this:
 
...
"properties" :
{
  "http://example.com/ns/foo" : "{\"a\" : \"Hello\", = \"b\" : 32}"
}
...
When working on WebFinger, there was a desire to keep it as simple as = possible.  However, I fully appreciate why some would want to do somet= hing like this.  Sometimes, linking to external resources is "ove= rkill" for the task at hand.  And, you're right that dealing with polymorphic data types can be a pain.  Then again, = the JSON parser deals with much of this automatically and the client is lik= ely going to only be looking for known members, anyway.
 
So, I'm not sure what to do here.  I'm OK with making a change.&n= bsp; It bothers me that we might break any client code that assumes all pro= perties are strings.  But, there is always the option to add some othe= r member named something other than "properties".
 
I take it you're not too keen on the idea, though.
 
Paul
 
------ Original Message ------
From: "Will Norris" <will@willnorris.com>
Cc: "webfinger@ietf.org" <webfinger@ietf.org>
Sent: 8/11/2014 11:39:19 PM
Subject: Re: [webfinger] Redefining "properties"
 
what are the actual use cases prompting this?  If fol= ks are trying to store more complicated data, why is it not just a linked r= esource?

Personally, as a client author, I've always hated it when APIs have po= lymorphic data types like this.


On Mon, Aug 11, 2014 at 7:29 PM, 'Paul E. Jones'= via WebFinger <webfing= er@googlegroups.com> wrote:
Folks,
 
I have been asked by multiple people for different purposes to see if = it might be possible to redefine "properties" in the JSON Resourc= e Descriptor.
 
Per RFC 7033, "properties" is defined as an object that has = zero or more name/value pairs whose values are strings or null.  The s= uggestion is that the values should be any valid JSON type.  Thus, a p= roperty might refer to a string (as is does now) or it might refer to an object or array.
 
This change would break any parsers strictly implement definition of &= quot;properties".  So, there are two questions I want to pre= sent to those who are interested:
 
1) Would you be agreeable to change the current definition of "pr= operties" to allow any value type?
2) If not, would be agreeable to introducing something like "prop= erties" that essentially allows for the same and, if so, what should t= his new object be named?
 
Personally, as much as I don't like breaking backward-compatibility, I= 'm favorable to redefining properties to accomodate what people want to do.=   I'm willing to work on an RFC 7033bis and/or a new RFC to update the= JRD specification, if folks are agreeable to either (1) or (2).
 
Paul
 

--

---
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 http= s://groups.google.com/d/optout.

--_000_4E1F6AAD24975D4BA5B16804296739439AE1FE1ETK5EX14MBXC293r_-- From nobody Sun Aug 17 20:37:00 2014 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC5D91A028A for ; Sun, 17 Aug 2014 20:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.622 X-Spam-Level: X-Spam-Status: No, score=0.622 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQcYowvLBjer for ; Sun, 17 Aug 2014 20:36:56 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 462181A0282 for ; Sun, 17 Aug 2014 20:36:56 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id v6so3633636lbi.39 for ; Sun, 17 Aug 2014 20:36:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=KpJNfGKXHyXodMHytttOgVjfGmzIEEFSv8iEqhJgCUE=; b=wCUqCBQIVRK4EF/uPocEITeYiR3BsqfGJmcLz47fOtpHaIolrYozGNyvoykuTVfX9e ebgqI00OdMTojNdprsXfURMG2ApVlWyj8XTatExHtYL6g00BB2TIVZhWZVU9Chqs34Pd sMcPB+eERjGE2xLq5UWu33/LdMgns9d0dJZ8QJmmlAjj5Hkr0j6Dtg7i6/BDAFT+VE3V yZSlWxcb1SpAtKNE+I0bmBzs+3IIxZxMwOLD7YBjmUysWT/EsKkIrkccuZbDgHcR/HEH qCstGSqa3F1+3HZilRoqeOW1EpxcEayER3Sl2dkE3HJicPKZXRsN8oHYTUZWqrbbT22v WUfQ== X-Received: by 10.152.179.168 with SMTP id dh8mr26923514lac.0.1408333014583; Sun, 17 Aug 2014 20:36:54 -0700 (PDT) MIME-Version: 1.0 Sender: wnorris@gmail.com Received: by 10.152.210.103 with HTTP; Sun, 17 Aug 2014 20:36:14 -0700 (PDT) In-Reply-To: References: From: Will Norris Date: Sun, 17 Aug 2014 20:36:14 -0700 X-Google-Sender-Auth: G7aDWwrKSfm1M-m8tdKMvyNXVgg Message-ID: To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=001a1133a55c0f4edd0500df1544 Archived-At: http://mailarchive.ietf.org/arch/msg/webfinger/RC1e2uzN5kJkq18YXqpa7dNkXyc Cc: "webfinger@ietf.org" Subject: Re: [webfinger] Redefining "properties" X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.15 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 Aug 2014 03:36:59 -0000 --001a1133a55c0f4edd0500df1544 Content-Type: text/plain; charset=UTF-8 On Sat, Aug 16, 2014 at 12:05 PM, 'Paul E. Jones' via WebFinger < webfinger@googlegroups.com> wrote: > Will, > > Sorry for the slow response. I've been busy. > > Yes, folks do want to put more complex data into JRD as opposed to > linking, including objects or arrays. I can see how this can be abused, > but then I can also see an argument for not linking to data that could be > trivially represented inside the JRD itself. > > Unfortunately, I do not have details of the specific use cases. > as a rule, I think suggestions for major changes to spec should always be accompanied by concrete use cases that necessitate the change, ever more so when we're talking about *breaking* changes to a *finalized* spec. (in this case Mike did provide an example later, so my comment is more to the fact that his was proposed in the first place without an actual use case in mind) > All I do know is that there people working on unrelated applications where > they want to be able to do things like this with WebFinger: > > "properties" : > { > "http://example.com/ns/foo" : > { > "a" : "Hello", > "b" : 32 > } > } > > Perhaps what might be worse is the possibility that people do this: > > ... > "properties" : > { > "http://example.com/ns/foo" : "{\"a\" : \"Hello\", \"b\" : 32}" > } > ... > When working on WebFinger, there was a desire to keep it as simple as > possible. However, I fully appreciate why some would want to do something > like this. Sometimes, linking to external resources is "overkill" for the > task at hand. And, you're right that dealing with polymorphic data types > can be a pain. Then again, the JSON parser deals with much of this > automatically and the client is likely going to only be looking for known > members, anyway. > it depends very much on what the code is doing. If you're just relying on a JSON parser to parse an unknown structure, it's unlikely anything too bad will happen. However, if you're specifically trying to unserialize the properties object into a string=>string map, then you would likely get a parsing error. > > So, I'm not sure what to do here. I'm OK with making a change. It > bothers me that we might break any client code that assumes all properties > are strings. > "client code that assumes all properties are strings" almost sounds like they took a shortcut or something. This could also be spelled "client code that implemented the spec as written"... *of course* they may have assumed properties would be strings, that's what the spec said they would be (or null). > But, there is always the option to add some other member named something > other than "properties". > > I take it you're not too keen on the idea, though. > I think that option should certainly be explored at least. In fact, that's something that can already be done today, no? I don't think webfinger precludes including other JSON values, does it? Certainly, making breaking changes does bother me, though I still don't think there as been THAT much adoption in the wild yet, so I don't know how much would really be at risk of breaking. What is the process for making this kind of change anyway? Publish an entirely new RFC that updates 7033? Publish a rewritten spec that obsoletes 7033 altogether? As a separate issue, and I don't recall to what extent this was discuss before, but this also makes me worry a little about the size of the data people are looking to add to a webfinger document. At least with links, you can request just the links you care about with the "rel" query parameter, but no such filtering mechanism exists for properties. Plus I have no idea how well supported the "rel" parameter is in webfinger servers anyway (I know I don't support it on my personal site, but that's just me). I know that nothing is stopping someone from throwing a megabyte worth of data in a property string today, so this "problem" (as much as it really is) already exists today. But I worry that changing properties to accept arbitrary JSON data may entice people to shove larger amounts of data in a JRD than perhaps should be. Gzip helps you to a degree, but I don't think JWT sets, for example, compress much. Ultimately, whether properties are strings or JSON objects, it's up to the application to decide where they're going to look for what data, and therefore what they instruct users to publish in their webfinger document. Perhaps what I'm suggesting is just that if new text does end up getting written to support JSON properties, then perhaps a note to implementors should be added to caution against adding too large of data (for some definition of "large")? -will ------ Original Message ------ > From: "Will Norris" > To: webfinger@googlegroups.com > Cc: "webfinger@ietf.org" > Sent: 8/11/2014 11:39:19 PM > Subject: Re: [webfinger] Redefining "properties" > > > what are the actual use cases prompting this? If folks are trying to > store more complicated data, why is it not just a linked resource? > > Personally, as a client author, I've always hated it when APIs have > polymorphic data types like this. > > > On Mon, Aug 11, 2014 at 7:29 PM, 'Paul E. Jones' via WebFinger < > webfinger@googlegroups.com> wrote: > >> Folks, >> >> I have been asked by multiple people for different purposes to see if it >> might be possible to redefine "properties" in the JSON Resource Descriptor. >> >> Per RFC 7033, "properties" is defined as an object that has zero or more >> name/value pairs whose values are strings or null. The suggestion is that >> the values should be any valid JSON type. Thus, a property might refer to >> a string (as is does now) or it might refer to an object or array. >> >> This change would break any parsers strictly implement definition of >> "properties". So, there are two questions I want to present to those who >> are interested: >> >> 1) Would you be agreeable to change the current definition of >> "properties" to allow any value type? >> 2) If not, would be agreeable to introducing something like "properties" >> that essentially allows for the same and, if so, what should this new >> object be named? >> >> Personally, as much as I don't like breaking backward-compatibility, I'm >> favorable to redefining properties to accomodate what people want to do. >> I'm willing to work on an RFC 7033bis and/or a new RFC to update the JRD >> specification, if folks are agreeable to either (1) or (2). >> >> 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/d/optout. >> > > -- > > --- > 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/d/optout. > --001a1133a55c0f4edd0500df1544 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, Aug 16, 2014 at 12:05 PM, 'Paul E. Jones' via WebFinger <webfinger@googlegroups.com> wrote:
Will,
=C2=A0
Sorry for the slow response.=C2=A0 I've been busy.
=C2=A0
Yes, folks=C2=A0do want to put more complex data into JRD as=C2=A0oppo= sed to linking, including objects or arrays.=C2=A0 I can see how this can b= e abused, but then I can also see an argument for not linking to data that = could be trivially represented inside the JRD itself.
=C2=A0
Unfortunately, I do not have details of the specific use cases.=C2=A0 =

as a rule, I thin= k suggestions for major changes to spec should always be accompanied by con= crete use cases that necessitate the change, ever more so when we're ta= lking about breaking changes to a finalized spec. =C2=A0(in t= his case Mike did provide an example later, so my comment is more to the fa= ct that his was proposed in the first place without an actual use case in m= ind)
=C2=A0
All I = do know is that there people working on unrelated applications where they= =C2=A0want to be able to=C2=A0 do things like this with WebFinger:
=C2=A0
"properties" :
{
=C2=A0 &qu= ot;http://example.com/ns/foo" :
=C2=A0 {
=C2=A0=C2=A0=C2=A0 "a" : "Hello",
=C2=A0= =C2=A0=C2=A0 "b" : 32
=C2=A0 }
}
=C2=A0
Perhaps what might be worse is the possibility that people do this:
=C2=A0
...
"properties" :
{
=C2= =A0 "http://example.com/ns/foo" : "{\"a\" : \"Hello\", \"= b\" : 32}"
}
...
When working on WebFinger, there was a desire to keep it as simple as = possible.=C2=A0 However, I fully appreciate why some would want to do somet= hing like this.=C2=A0 Sometimes, linking to external resources is "ove= rkill" for the task at hand.=C2=A0 And, you're right that dealing = with polymorphic data types can be a pain.=C2=A0 Then again, the JSON parse= r deals with much of this automatically and the client is likely going to o= nly be looking for known members, anyway.

it depends very much on what the cod= e is doing. =C2=A0If you're just relying on a JSON parser to parse an u= nknown structure, it's unlikely anything too bad will happen. =C2=A0How= ever, if you're specifically trying to unserialize the properties objec= t into a string=3D>string map, then you would likely get a parsing error= .
=C2=A0
=C2=A0
So, I'm not sure what to do here.=C2=A0 I'm OK with making a c= hange.=C2=A0 It bothers me that we might break any client code that assumes= all properties are strings.=C2=A0

=
"client code that assumes all properties are strings" almost= sounds like they took a shortcut or something. =C2=A0This could also be sp= elled "client code that implemented the spec as written"... of= course they may have assumed properties would be strings, that's w= hat the spec said they would be (or null).
=C2=A0
But, there is alw= ays the option to add some other member named something other than "pr= operties".
=C2=A0
I take it you're not too keen on the idea, though.

I think that option should certainly be explor= ed at least. =C2=A0In fact, that's something that can already be done t= oday, no? =C2=A0I don't think webfinger precludes including other JSON = values, does it?

Certainly, making breaking changes does bother me, thou= gh I still don't think there as been THAT much adoption in the wild yet= , so I don't know how much would really be at risk of breaking. =C2=A0W= hat is the process for making this kind of change anyway? =C2=A0Publish an = entirely new RFC that updates 7033? =C2=A0Publish a rewritten spec that obs= oletes 7033 altogether?


As a separate issue, and I don't rec= all to what extent this was discuss before, but this also makes me worry a = little about the size of the data people are looking to add to a webfinger = document. =C2=A0At least with links, you can request just the links you car= e about with the "rel" query parameter, but no such filtering mec= hanism exists for properties. =C2=A0Plus I have no idea how well supported = the "rel" parameter is in webfinger servers anyway (I know I don&= #39;t support it on my personal site, but that's just me).

I know that nothing is stopping someone from throwing a= megabyte worth of data in a property string today, so this "problem&q= uot; (as much as it really is) already exists today. =C2=A0But I worry that= changing properties to accept arbitrary JSON data may entice people to sho= ve larger amounts of data in a JRD than perhaps should be. =C2=A0Gzip helps= you to a degree, but I don't think JWT sets, for example, compress muc= h.

Ultimately, whether properties are strings or JSON obje= cts, it's up to the application to decide where they're going to lo= ok for what data, and therefore what they instruct users to publish in thei= r webfinger document. =C2=A0Perhaps what I'm suggesting is just that if= new text does end up getting written to support JSON properties, then perh= aps a note to implementors should be added to caution against adding too la= rge of data (for some definition of "large")?

-will


------ Original Message ------
From: "Will Norris" <will@willnorris.com>
Sent: 8/11/2014 11:39:19 PM
Subject: Re: [webfinger] Redefining "properties"
=C2=A0
what are the actual use cases prompting this? =C2=A0If fol= ks are trying to store more complicated data, why is it not just a linked r= esource?=20

Personally, as a client author, I've always hated it when APIs hav= e polymorphic data types like this.


On Mon, Aug 11, 2014 at 7:29 PM, 'Paul E. Jo= nes' via WebFinger <webfinger@googlegroups.com>= wrote:
Folks,
=C2=A0
I have been asked by multiple people for different purposes to see if = it might be possible to redefine "properties" in the JSON Resourc= e Descriptor.
=C2=A0
Per RFC 7033, "properties" is defined as an object that has = zero or more name/value pairs whose values are strings or null.=C2=A0 The s= uggestion is that the values should be any valid JSON type.=C2=A0 Thus, a p= roperty might refer to a string (as is does now) or it might refer to an ob= ject or array.
=C2=A0
This change would break any parsers strictly implement definition of &= quot;properties".=C2=A0 So, there are=C2=A0two questions I want to pre= sent to those who are interested:
=C2=A0
1) Would you be agreeable to change the current definition of "pr= operties"=C2=A0to allow any value type?
2) If not, would be agreeable to introducing something like "prop= erties" that essentially allows for the same and, if so, what should t= his new object be named?
=C2=A0
Personally, as much as I don't like breaking backward-compatibilit= y, I'm favorable to redefining properties to accomodate what people wan= t to do.=C2=A0 I'm willing to work on an RFC 7033bis and/or a new RFC t= o update the JRD specification, if folks are agreeable to either (1) or (2)= .
=C2=A0
Paul
=C2=A0

--

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

--

---
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/d/optout.

--001a1133a55c0f4edd0500df1544-- From nobody Mon Aug 18 17:10:18 2014 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C89D1A0B0A for ; Mon, 18 Aug 2014 17:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URacptFmwuZE for ; Mon, 18 Aug 2014 17:10:14 -0700 (PDT) Received: from mail-qg0-f46.google.com (mail-qg0-f46.google.com [209.85.192.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 226201A0B05 for ; Mon, 18 Aug 2014 17:10:13 -0700 (PDT) Received: by mail-qg0-f46.google.com with SMTP id z60so1815179qgd.19 for ; Mon, 18 Aug 2014 17:10:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=Y6x6KmPM9QWsZ3GNx5jTYVI+U+Cu+b/yYsZuAqQwEsM=; b=bWBM4Dgdbva7GopyDtUdB1DCE835qhI5a1+dxi489kxZ4nlTKqY64yYZ41i5vS+tiH 8lTsj/+JG2RiqpE9sqfUVZN8u0IyZNgW2BboOQXGGcTGFzxkJxACWO2SRttfdjfxgfAg yIJJq3IosnZxK+xVam2p6oi6kaHez4Pq0W1Wo53ptx+PE7U+fzCNxk2TB9c7rqJn2Ih+ 5X7tCP+acf8jSAPXpnfLvVcNx4uDGqMAw6NbUARCD5dQtpBcvle8g2XbgHSo8wKWVapI 2d7qjTbC+PoBNn78EQMJiyHV8gEqr61Jhpvjpi6BaIaudtvI4jqM7FK1oT9avYY+CWqJ aPMw== X-Gm-Message-State: ALoCoQlKT7ZVrOw0yrU4dS8zhKRN5SziPzbjfseC03ukN7PPNsPFpmki4s4+HAbwDTysnj4PXbZs X-Received: by 10.224.74.1 with SMTP id s1mr62068680qaj.61.1408407013058; Mon, 18 Aug 2014 17:10:13 -0700 (PDT) Received: from [192.168.8.103] ([201.188.7.206]) by mx.google.com with ESMTPSA id u14sm32230277qau.43.2014.08.18.17.10.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 Aug 2014 17:10:12 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_C4511973-0865-4417-9C36-3DE97E0BAEB9" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Bradley In-Reply-To: Date: Mon, 18 Aug 2014 20:10:13 -0400 Message-Id: <34087713-90B2-4B60-AA14-F5FF617C7C8C@ve7jtb.com> References: To: webfinger@googlegroups.com X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/webfinger/J7G2BNiLw3a7m8Z5Nsxk5StAebk Cc: "webfinger@ietf.org" Subject: Re: [webfinger] Redefining "properties" X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.15 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, 19 Aug 2014 00:10:17 -0000 --Apple-Mail=_C4511973-0865-4417-9C36-3DE97E0BAEB9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I will also note that embedding a JWKS directly is not necessarily a = good thing unless you are dynamically generating the JRD. In Connect registration we originally only had jwks_uri to include them = by reference. Allowing a client to push a JWK inline came later. JWKS can easily be referenced with a link from a JRD. There may be = other resins to allow complex types but I don=92t think JWKS inline is a = compelling one. John B. On Aug 17, 2014, at 11:36 PM, Will Norris wrote: > On Sat, Aug 16, 2014 at 12:05 PM, 'Paul E. Jones' via WebFinger = wrote: > Will, > =20 > Sorry for the slow response. I've been busy. > =20 > Yes, folks do want to put more complex data into JRD as opposed to = linking, including objects or arrays. I can see how this can be abused, = but then I can also see an argument for not linking to data that could = be trivially represented inside the JRD itself. > =20 > Unfortunately, I do not have details of the specific use cases.=20 >=20 > as a rule, I think suggestions for major changes to spec should always = be accompanied by concrete use cases that necessitate the change, ever = more so when we're talking aboutbreaking changes to a finalized spec. = (in this case Mike did provide an example later, so my comment is more = to the fact that his was proposed in the first place without an actual = use case in mind) > =20 > All I do know is that there people working on unrelated applications = where they want to be able to do things like this with WebFinger: > =20 > "properties" : > { > "http://example.com/ns/foo" : > { > "a" : "Hello", > "b" : 32 > } > } > =20 > Perhaps what might be worse is the possibility that people do this: > =20 > ... > "properties" : > { > "http://example.com/ns/foo" : "{\"a\" : \"Hello\", \"b\" : 32}" > } > ... > When working on WebFinger, there was a desire to keep it as simple as = possible. However, I fully appreciate why some would want to do = something like this. Sometimes, linking to external resources is = "overkill" for the task at hand. And, you're right that dealing with = polymorphic data types can be a pain. Then again, the JSON parser deals = with much of this automatically and the client is likely going to only = be looking for known members, anyway. >=20 > it depends very much on what the code is doing. If you're just = relying on a JSON parser to parse an unknown structure, it's unlikely = anything too bad will happen. However, if you're specifically trying to = unserialize the properties object into a string=3D>string map, then you = would likely get a parsing error. > =20 > =20 > So, I'm not sure what to do here. I'm OK with making a change. It = bothers me that we might break any client code that assumes all = properties are strings.=20 >=20 > "client code that assumes all properties are strings" almost sounds = like they took a shortcut or something. This could also be spelled = "client code that implemented the spec as written"... of course they may = have assumed properties would be strings, that's what the spec said they = would be (or null). > =20 > But, there is always the option to add some other member named = something other than "properties". > =20 > I take it you're not too keen on the idea, though. >=20 > I think that option should certainly be explored at least. In fact, = that's something that can already be done today, no? I don't think = webfinger precludes including other JSON values, does it? >=20 > Certainly, making breaking changes does bother me, though I still = don't think there as been THAT much adoption in the wild yet, so I don't = know how much would really be at risk of breaking. What is the process = for making this kind of change anyway? Publish an entirely new RFC that = updates 7033? Publish a rewritten spec that obsoletes 7033 altogether? >=20 >=20 > As a separate issue, and I don't recall to what extent this was = discuss before, but this also makes me worry a little about the size of = the data people are looking to add to a webfinger document. At least = with links, you can request just the links you care about with the "rel" = query parameter, but no such filtering mechanism exists for properties. = Plus I have no idea how well supported the "rel" parameter is in = webfinger servers anyway (I know I don't support it on my personal site, = but that's just me). >=20 > I know that nothing is stopping someone from throwing a megabyte worth = of data in a property string today, so this "problem" (as much as it = really is) already exists today. But I worry that changing properties = to accept arbitrary JSON data may entice people to shove larger amounts = of data in a JRD than perhaps should be. Gzip helps you to a degree, = but I don't think JWT sets, for example, compress much. >=20 > Ultimately, whether properties are strings or JSON objects, it's up to = the application to decide where they're going to look for what data, and = therefore what they instruct users to publish in their webfinger = document. Perhaps what I'm suggesting is just that if new text does end = up getting written to support JSON properties, then perhaps a note to = implementors should be added to caution against adding too large of data = (for some definition of "large")? >=20 > -will >=20 >=20 > ------ Original Message ------ > From: "Will Norris" > To: webfinger@googlegroups.com > Cc: "webfinger@ietf.org" > Sent: 8/11/2014 11:39:19 PM > Subject: Re: [webfinger] Redefining "properties" > =20 >> what are the actual use cases prompting this? If folks are trying to = store more complicated data, why is it not just a linked resource? >>=20 >> Personally, as a client author, I've always hated it when APIs have = polymorphic data types like this. >>=20 >>=20 >> On Mon, Aug 11, 2014 at 7:29 PM, 'Paul E. Jones' via WebFinger = wrote: >> Folks, >> =20 >> I have been asked by multiple people for different purposes to see if = it might be possible to redefine "properties" in the JSON Resource = Descriptor. >> =20 >> Per RFC 7033, "properties" is defined as an object that has zero or = more name/value pairs whose values are strings or null. The suggestion = is that the values should be any valid JSON type. Thus, a property = might refer to a string (as is does now) or it might refer to an object = or array. >> =20 >> This change would break any parsers strictly implement definition of = "properties". So, there are two questions I want to present to those = who are interested: >> =20 >> 1) Would you be agreeable to change the current definition of = "properties" to allow any value type? >> 2) If not, would be agreeable to introducing something like = "properties" that essentially allows for the same and, if so, what = should this new object be named? >> =20 >> Personally, as much as I don't like breaking backward-compatibility, = I'm favorable to redefining properties to accomodate what people want to = do. I'm willing to work on an RFC 7033bis and/or a new RFC to update = the JRD specification, if folks are agreeable to either (1) or (2). >> =20 >> Paul >> =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/d/optout. >>=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/d/optout. >=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/d/optout. --Apple-Mail=_C4511973-0865-4417-9C36-3DE97E0BAEB9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I will = also note that embedding a JWKS directly is not necessarily a good thing = unless you are dynamically generating the JRD.

In = Connect registration we originally only had jwks_uri to include them by = reference.  Allowing a client to push a JWK inline came = later.

JWKS can easily be referenced with a = link from a JRD.  There may be other resins to allow complex types = but I don=92t think JWKS inline is a compelling = one.

John B.

On Aug 17, = 2014, at 11:36 PM, Will Norris <will@willnorris.com> = wrote:

On = Sat, Aug 16, 2014 at 12:05 PM, 'Paul E. Jones' via WebFinger <webfinger@googlegroups.com> wrote:
Will,
 
Sorry for the slow = response.  I've been busy.
 
Yes, = folks do want to put more complex data into JRD as opposed to = linking, including objects or arrays.  I can see how this can be = abused, but then I can also see an argument for not linking to data that = could be trivially represented inside the JRD = itself.
 
Unfortunately, I do not have = details of the specific use = cases. 

as a rule, I = think suggestions for major changes to spec should always be accompanied = by concrete use cases that necessitate the change, ever more so when = we're talking aboutbreaking changes to a finalized spec.  (in this case = Mike did provide an example later, so my comment is more to the fact = that his was proposed in the first place without an actual use case in = mind)
 
All I do know is that there people = working on unrelated applications where they want to be able = to  do things like this with = WebFinger:
 
"properties" :
{
  "http://example.com/ns/foo" = :
  {
    "a" : = "Hello",
    "b" : 32
  }
}
 
Perhaps what might be worse is the possibility = that people do this:
 
...
"properties" :
{
  "http://example.com/ns/foo" : = "{\"a\" : \"Hello\", \"b\" : 32}"
}
...
When = working on WebFinger, there was a desire to keep it as simple as = possible.  However, I fully appreciate why some would want to do = something like this.  Sometimes, linking to external resources is = "overkill" for the task at hand.  And, you're right that dealing = with polymorphic data types can be a pain.  Then again, the JSON = parser deals with much of this automatically and the client is likely = going to only be looking for known members, = anyway.

it depends very much on = what the code is doing.  If you're just relying on a JSON parser to = parse an unknown structure, it's unlikely anything too bad will happen. =  However, if you're specifically trying to unserialize the = properties object into a string=3D>string map, then you would likely = get a parsing error.
 
 
So, = I'm not sure what to do here.  I'm OK with making a change.  = It bothers me that we might break any client code that assumes all = properties are = strings. 

"client code that = assumes all properties are strings" almost sounds like they took a = shortcut or something.  This could also be spelled "client code = that implemented the spec as written"... of course they may have assumed = properties would be strings, that's what the spec said they would be (or = null).
 
But, there is always the option to add some = other member named something other than = "properties".
 
I take it you're not too keen = on the idea, though.

I think that = option should certainly be explored at least.  In fact, that's = something that can already be done today, no?  I don't think = webfinger precludes including other JSON values, does = it?

Certainly, making breaking changes does = bother me, though I still don't think there as been THAT much adoption = in the wild yet, so I don't know how much would really be at risk of = breaking.  What is the process for making this kind of change = anyway?  Publish an entirely new RFC that updates 7033? =  Publish a rewritten spec that obsoletes 7033 = altogether?


As a separate issue, = and I don't recall to what extent this was discuss before, but this also = makes me worry a little about the size of the data people are looking to = add to a webfinger document.  At least with links, you can request = just the links you care about with the "rel" query parameter, but no = such filtering mechanism exists for properties.  Plus I have no = idea how well supported the "rel" parameter is in webfinger servers = anyway (I know I don't support it on my personal site, but that's just = me).

I know that nothing is stopping someone = from throwing a megabyte worth of data in a property string today, so = this "problem" (as much as it really is) already exists today.  But = I worry that changing properties to accept arbitrary JSON data may = entice people to shove larger amounts of data in a JRD than perhaps = should be.  Gzip helps you to a degree, but I don't think JWT sets, = for example, compress much.

Ultimately, whether = properties are strings or JSON objects, it's up to the application to = decide where they're going to look for what data, and therefore what = they instruct users to publish in their webfinger document. =  Perhaps what I'm suggesting is just that if new text does end up = getting written to support JSON properties, then perhaps a note to = implementors should be added to caution against adding too large of data = (for some definition of = "large")?

-will


------ Original Message = ------
From: "Will = Norris" <will@willnorris.com>
Sent: 8/11/2014 = 11:39:19 PM
Subject: Re: [webfinger] Redefining = "properties"
 
what are the actual use cases = prompting this?  If folks are trying to store more complicated = data, why is it not just a linked = resource?

Personally, as a client author, I've always = hated it when APIs have polymorphic data types like = this.


On Mon, Aug 11, 2014 at 7:29 PM, 'Paul E. Jones' = via WebFinger <webfinger@googlegroups.com> wrote:
Folks,
 
I = have been asked by multiple people for different purposes to see if it = might be possible to redefine "properties" in the JSON Resource = Descriptor.
 
Per RFC 7033, "properties" is = defined as an object that has zero or more name/value pairs whose values = are strings or null.  The suggestion is that the values should be = any valid JSON type.  Thus, a property might refer to a string (as = is does now) or it might refer to an object or = array.
 
This change would break any parsers = strictly implement definition of "properties".  So, there = are two questions I want to present to those who are = interested:
 
1) Would you be agreeable to = change the current definition of "properties" to allow any value = type?
2) If not, would be agreeable to introducing something = like "properties" that essentially allows for the same and, if so, what = should this new object be named?
 
Personally, = as much as I don't like breaking backward-compatibility, I'm favorable = to redefining properties to accomodate what people want to do.  I'm = willing to work on an RFC 7033bis and/or a new RFC to update the JRD = specification, if folks are agreeable to either (1) or = (2).
 
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/d/optout.


-- 

--- 
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/d/optout.
<= /blockquote>


-- 

--- 
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.com/d/op= tout.

= --Apple-Mail=_C4511973-0865-4417-9C36-3DE97E0BAEB9--