Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD)

Michael Thomas <> Tue, 24 April 2012 21:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AE77511E80AB; Tue, 24 Apr 2012 14:00:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.261
X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, J_CHICKENPOX_33=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5j-v1RwVq2P1; Tue, 24 Apr 2012 14:00:44 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3272A11E8074; Tue, 24 Apr 2012 14:00:44 -0700 (PDT)
Received: from ( []) (authenticated bits=0) by (8.14.3/8.14.3) with ESMTP id q3OL0gj0027071 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 24 Apr 2012 14:00:43 -0700
Message-ID: <>
Date: Tue, 24 Apr 2012 14:00:42 -0700
From: Michael Thomas <>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv: Gecko/20090605 Thunderbird/ Mnenhy/
MIME-Version: 1.0
To: Derek Atkins <>
References: <> <> <> <> <> <> <091401cd1ea3$e159be70$a40d3b50$> <> <091901cd1eb0$167a8ce0$436fa6a0$> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2331; t=1335301243; x=1336165243; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;;; z=From:=20Michael=20Thomas=20<> |Subject:=20Re=3A=20[OAUTH-WG]=20[apps-discuss]=20Web=20Fin ger=20vs.=20Simple=20Web=20Discovery=0A=20(SWD) |Sender:=20 |To:=20Derek=20Atkins=20<> |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=ZRm2iFlcuB1ZSWNJCMNNNFq4umlLCvS4RWBuA48Ctms=; b=Gx9lVvhBCoBxrCpKx7obJhfJFwGbz7r+/VQ03FOmDD+wVfXRNL7Xek1ic2 m2cFOtSuDtOtkYZuIIuPIrxtE7vguToG5Mc+6ipUxoK5OHPx8m0Z6uqzkUhY fSJa1MCjdPB5OwU/sJxIVtC49/iUSiedsi9cNbraNkGOm4hHS30ms=;
Authentication-Results: ; v=0.1; dkim=pass ( sig from verified; ); dkim-asp=pass
Cc: 'Tim Bray' <>,, 'Apps Discuss' <>
Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 24 Apr 2012 21:00:44 -0000

On 04/23/2012 09:55 AM, Derek Atkins wrote:
> Michael Thomas<>  writes:
>> Derek Atkins wrote:
>>> Michael Thomas<>  writes:
>>>> Why not MUST ASN.1 while you're at it? JSON has won in case
>>>> you'all haven't noticed it.
>>> Well, now that you mention it...   ;-)
>>> But seriously, we're basing this work on an RFC that was just release
>>> six months ago and it requires XML.  Why be so quick to drop something
>>> we just published half a year ago?  So maybe in 6 months we drop JSON
>>> and add the next big thing?  Come on, Mike.
>>> I agree, we should definitely support JSON.  But I also think we should
>>> support XML.  The client can do what it wants, which is where want the
>>> light weight implementation.
>> I think you're probably misunderstanding me. I'm (I believe) with Tim
>> in saying "pick one". Just one. For clients and servers. And I'm only
> No, I'm not misunderstanding you, I know exactly what you are arguing
> for.  And I'm agreeing with you that we must support JSON.  However, I
> disagree that we should drop XML, especially considering 6415 requires
> XML and it was just released 6 months ago.
> I'm also saying that this is only a server-side requirement to support
> both.  The client can choose to support only one based on its own
> requirements.  If you already have an XML-based client, why force them
> to add JSON support?  Similarly, if you already have a JSON-based
> client, why force them to add XML support?
> If you're writing a client, you can ignore XML and only play with JSON.

Derek -- I think that the modern reality is that most things can
support both without much problem from a code footprint and
library availability standpoint,  both client and server. But that
misses a larger point of whether we _should_ just because we
_can_. There is a cost to maintaining two different encoding/
decoding both on the implementation side, as well as the
specification (and the debugging thereof) side. So my feeling
is that "chose one" should *always* be a SHOULD in the way
that Stephen outlined as well. If that means choosing XML
mainly for historical reasons, that's still better than trying to
placate both sides or "facilitating the transition" or any other
reason on offer.