- From: Brad Fitzpatrick <bradfitz@google.com>
- Date: Thu, 1 Nov 2012 15:43:47 +0100
- To: webfinger@googlegroups.com
- Cc: apps-discuss@ietf.org, public-fedsocweb@w3.org
- Message-ID: <CAAkTpCr3XxWE2Cm3usWksKEyZwxn9n6zDW90ELJMN4wpjcTphA@mail.gmail.com>
On Thu, Nov 1, 2012 at 7:40 AM, Paul E. Jones <paulej@packetizer.com> wrote: > Folks,**** > > ** ** > > Here’s a proposal that some might find acceptable and others will probably > love. It’s just a proposal, so no bazookas, please, from those who will > find it troubling ;-)**** > > ** ** > > > http://hive.packetizer.com/users/paulej/internet-drafts/draft-ietf-appsawg-webfinger-03-ALT.txt > Much nicer! > **** > > ** What I did with this text is the following: > > ** > > **· **Included all of the current -03 text (not yet published, > but text folks proposed on the list)**** > > **· **Removed every reference to XML and XRD**** > > **· **Stated that the default format for > /.well-known/host-meta.json is JRD**** > > **· **Stated that the default format for /.well-known/host-meta > is implementation-dependent, so clients MUST use the Accept header to > explicitly request the desired representation when using that resource > (this is key to backward/forward compatibility and proper use of HTTP and > Accept)**** > > **· **Removed the “account link relation” section**** > > **· **Removed the interop considerations section, since some feel > there is no need and I think requiring use of “Accept” on host-meta will > address any interop concerns**** > > **· **Removed the XML appendix that gave some people heartburn**** > > ** ** > > This shaved off 6 pages of text, I think will still give us > backward-compatibility for those who have asked for it, but more clearly > positions JSON / JRD as the only format developers need to worry with.**** > > ** ** > > Tell me what you think. > Some notes I took while reading: * Delete the whole section "4.2. Simplifying the Login Process". As much as I loves me some OpenID, it's out of place in this document. * WebFinger, being JSON-only, should only document /.well-known/host-meta.json as part of the client's discovery process, not /.well-known/host-meta. Status.net and whoever else can continue to serve webfinger for compatibility at /.well-known/host-meta if they'd like to support all of RFC 6415. But WebFinger doesn't need to include docs on supporting all of RFC 6415. It should be possible to write a server which is WebServer compliant without being 6415 compliant. * Section 5.2: ditch the rel=, resource= parameters from host-meta.json. It's a HOST meta, not a RESOURCE meta. It's being morphed into an all-encompassing endpoint. If you really want this, DO NOT REUSE host-meta and just use /.well-known/webfinger-query. But I am not proposing that. I'm just saying that would be more sane than tacking random crap onto host-meta. * Section 6. MUST support CORS, but MAY exclude the header. What? SHOULD probably. * Section 8.1: "When a query is issued host-meta" ... "pointing to the location of the hosted WebFinger service URL" host-meta is its own thing. You are assuming that host-meta means WebFinger. I might have more minor feedback later, but the above is most of it.
Received on Thursday, 1 November 2012 14:44:18 UTC