So you are guaranteeing that there are no clients using WF today?
>________________________________
> From: Mike Jones <michael.jo...@microsoft.com>
>To: Paul E. Jones <pau...@packetizer.com>; 'Murray S. Kucherawy'
><m...@cloudmark.com>; "oauth@ietf.org" <oauth@ietf.org>; 'Apps Discuss'
><apps-disc...@ietf.org>
>Sent: Thursday, April 19, 2012 10:48 PM
>Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery
>(SWD)
>
>To be clear, making this mandatory would break no clients. It would require
>updating some servers, just as requiring JSON would. This seems like a fair
>tradeoff when it makes an appreciable difference in user interface latency in
>some important scenarios. If you and the other key WebFinger supporters can
>agree to making "resource" support mandatory and requiring JSON, I believe we
>may have a path forward.
>
> Cheers,
> -- Mike
>
>-----Original Message-----
>From: Paul E. Jones [mailto:pau...@packetizer.com]
>Sent: Thursday, April 19, 2012 10:39 PM
>To: Mike Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps Discuss'
>Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery
>(SWD)
>
>That's correct. We could certainly make it mandatory, but the reason it isn't
>is to maintain backward compatibility with existing deployments.
>
>I think we should always think carefully when we decide to make a change that
>breaks backward-compatibility. This is one change that would do that.
>
>Paul
>
>> -----Original Message-----
>> From: Mike Jones [mailto:michael.jo...@microsoft.com]
>> Sent: Friday, April 20, 2012 1:10 AM
>> To: Paul E. Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps Discuss'
>> Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web
>> Discovery
>> (SWD)
>>
>> Currently, support for the "resource" parameter is optional, as per
>> the following (correct?):
>>
>> Note that support for the "resource" parameter is optional, but
>> strongly RECOMMENDED for improved performance. If a server does not
>> implement the "resource" parameter, then the server's host metadata
>> processing logic remains unchanged from RFC 6415.
>>
>> To truly support 1, this would need to be changed to REQUIRED, correct?
>>
>> -- Mike
>>
>> -----Original Message-----
>> From: Paul E. Jones [mailto:pau...@packetizer.com]
>> Sent: Thursday, April 19, 2012 8:16 PM
>> To: Mike Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps Discuss'
>> Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web
>> Discovery
>> (SWD)
>>
>> Mike,
>>
>> > There are two criteria that I would consider to be essential
>> > requirements for any resulting general-purpose discovery specification:
>> >
>> > 1. Being able to always discover per-user information with a single
>> > GET (minimizing user interface latency for mobile devices, etc.)
>>
>> WF can do that. See:
>> $ curl -v https://packetizer.com/.well-known/\
>> host-meta.json?resource=acct:pau...@packetizer.com
>>
>> > 2. JSON should be required and it should be the only format
>> > required (simplicity and ease of deployment/adoption)
>>
>> See the above example. However, I also support XML with my server.
>> It took me less than 10 minutes to code up both XML and JSON representations.
>> Once the requested format is determined, the requested URI is
>> determined, data is pulled from the database, spitting out the desired
>> format is trivial.
>>
>> Note, and very important note: supporting both XML and JSON would only
>> be a server-side requirement. The client is at liberty to use the
>> format it prefers. I would agree that forcing a client to support
>> both would be unacceptable, but the server? Nothing to it.
>>
>> > SWD already meets those requirements. If the resulting spec meets
>> > those requirements, it doesn't matter a lot whether we call it
>> > WebFinger or Simple Web Discovery, but I believe that the
>> > requirements discussion is probably the most productive one to be
>> > having at this point - not the starting point document.
>>
>> I believe WebFinger meets those requirements. We could debate whether
>> XML should be supported, but I'll note (again) that it is there in RFC 6415.
>> That document isn't all that old and, frankly, it concerns me that we
>> would have a strong preference for format A one week and then Format B
>> the next.
>> We are where we are and I can see reason for asking for JSON, but no
>> good reason to say we should not allow XML (on the server side).
>>
>> Paul
>>
>>
>>
>
>
>
>
>_______________________________________________
>OAuth mailing list
>OAuth@ietf.org
>https://www.ietf.org/mailman/listinfo/oauth
>
>
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
