[webfinger] Redefining "properties"

"Paul E. Jones" <paulej@packetizer.com> Tue, 12 August 2014 02:29 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 []) by ietfa.amsl.com (Postfix) with ESMTP id ACCFD1A0119 for <webfinger@ietfa.amsl.com>; 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id slKr0QyACjZt for <webfinger@ietfa.amsl.com>; Mon, 11 Aug 2014 19:29:16 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com []) (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 <webfinger@ietf.org>; Mon, 11 Aug 2014 19:29:16 -0700 (PDT)
Received: from [] (cpe-024-211-197-136.nc.res.rr.com []) (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" <paulej@packetizer.com>
To: webfinger@ietf.org, "webfinger@googlegroups.com" <webfinger@googlegroups.com>
Date: Tue, 12 Aug 2014 02:29:33 +0000
Message-Id: <em1c919200-3d1f-455f-bd2b-59a9ed03dd24@sydney>
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" <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: Tue, 12 Aug 2014 02:29:18 -0000


I have been asked by multiple people for different purposes to see if it 
might be possible to redefine "properties" in the JSON Resource 

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 

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