Re: [webfinger] Redefining "properties"

"Paul E. Jones" <paulej@packetizer.com> Sat, 16 August 2014 19:05 UTC

Return-Path: <paulej@packetizer.com>
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 <webfinger@ietfa.amsl.com>; 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 <webfinger@ietfa.amsl.com>; 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 <webfinger@ietf.org>; 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" <paulej@packetizer.com>
To: "Will Norris" <will@willnorris.com>, webfinger@googlegroups.com
Date: Sat, 16 Aug 2014 19:05:45 +0000
Message-Id: <em6aba2e86-7b0f-49d3-a041-49439c5f7df4@sydney>
In-Reply-To: <CAJqAn3ysg30qZndNpUvk=kUK0ZCcQrW652E_6-0-+q_ceFPHAA@mail.gmail.com>
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" <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" <paulej@packetizer.com>
List-Id: Discussion of the Webfinger protocol proposal in the Applications Area <webfinger.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/webfinger>, <mailto:webfinger-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/webfinger/>
List-Post: <mailto:webfinger@ietf.org>
List-Help: <mailto:webfinger-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/webfinger>, <mailto:webfinger-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 Aug 2014 19:05:34 -0000

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

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.  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@willnorris.com>;
To: webfinger@googlegroups.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 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.
>