[webfinger] Revised WebFinger spec (draft -15)

"Paul E. Jones" <paulej@packetizer.com> Thu, 04 July 2013 04:36 UTC

Return-Path: <paulej@packetizer.com>
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 E000911E8129 for <webfinger@ietfa.amsl.com>; Wed, 3 Jul 2013 21:36:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BJXz2ZJkfcNc for <webfinger@ietfa.amsl.com>; Wed, 3 Jul 2013 21:36:54 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 82BBD11E811A for <webfinger@ietf.org>; Wed, 3 Jul 2013 21:36:54 -0700 (PDT)
Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r644akBB028537 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 4 Jul 2013 00:36:46 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1372912607; bh=Yr0fAVMRLyWzvQ9fd3F/LS2Q5l8LFw2xI+S8GTddpYk=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding; b=sKA5NYk9bZoT15ZhP69XMK5n2qjJBp8eCGHqSXNgzqM/safVbrKYz/hygMZkvl+dq yE9V+dUZJXi4oU7avKqZlazr7H3iHFfq4HSojxWlLx9RmDYwMf0KhdH7c29VkIP1r/ 77T7aBtULnWbJx3Rata2LyxxqJ9nJs7hDsZDKTV4=
From: "Paul E. Jones" <paulej@packetizer.com>
To: 'Mike Jones' <Michael.Jones@microsoft.com>, 'Pete Resnick' <presnick@qti.qualcomm.com>, 'Barry Leiba' <barryleiba@computer.org>
Date: Thu, 04 Jul 2013 00:37:21 -0400
Message-ID: <0a8601ce7870$2ceef090$86ccd1b0$@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: Ac54b/+RVaeOYKm0QymkYkIBmSl/TQ==
Content-Language: en-us
Cc: 'salvatore loreto' <salvatore.loreto@ericsson.com>, 'webfinger' <webfinger@ietf.org>, 'Melvin Carvalho' <melvincarvalho@gmail.com>, draft-ietf-appsawg-webfinger@tools.ietf.org
Subject: [webfinger] Revised WebFinger spec (draft -15)
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 <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: Thu, 04 Jul 2013 04:36:59 -0000

Folks,

Having reviewed the thread below and taken other input into consideration, I
revised the WebFinger document and it now appears as draft -15.

Here's a summary of changes and responses on some comments made:

* Most significantly, I removed all of the contentious examples.  I kept
  the OpenID Connect example and brought over an "http" example from RFC
6415.
  Neither should be contentious, since the first is a concrete example
  from OpenID and the second is an example that existed already in an RFC.
  No example email auto config, device: URI, or locating a blog given an
email
  Address.  

* I did not change the language to say that WF is a framework.  It is a
protocol
  with a well-defined syntax, not unlike HTTP. What one requests and what
  payload, like HTTP, is really outside the scope of the spec.  That said,
  Section 1 states that applications that desire to use WF must specify
  "properties, titles, and link relation types that are appropriate for the
  application".  Is this sufficient to address this concern?

* There was a suggestion to define a "rel" registry.  Such a registry
  already exists: http://www.iana.org/assignments/link-relations/

* Clarified that some server responses may have either an empty links array
  or no links array.  (No change in behavior, but this clarification was
  requested.)

* I removed text in section 4.5 that recommends the use of the acct URI
  scheme.  Applications / usage specifications will indicate what scheme
  to use and we do not need to dance around this issue in the protocol spec.

* A few minor edits (e.g., references and word choice)

You can find the current text here:
http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-15

Paul