[Openid-specs-ab] Spec call notes 25-Aug-11
Anthony Nadalin
tonynad at microsoft.com
Mon Aug 29 13:31:43 UTC 2011
> I don't think that clients should specify the size using the Accept HTTP header, since some clients (like javascript clients) may not be able to easily set the header.
Agree
From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Andreas Åkre Solberg
Sent: Monday, August 29, 2011 3:54 AM
To: Allen Tom
Cc: openid-specs-ab at lists.openid.net
Subject: Re: [Openid-specs-ab] Spec call notes 25-Aug-11
On 26. aug. 2011, at 20:33, Allen Tom wrote:
I don't think that clients should specify the size using the Accept HTTP header, since some clients (like javascript clients) may not be able to easily set the header.
I agree, I did not intend to suggest providing size preferences using the Accept header (I don't think there even is a standard for that).
Instead I was thinking of the image format (png versus gif versus svg). In that case, I would say it does not matter that you cannot set the header using javascript, as the user agent probably will send the 'correct' format preferences anyway. in example a web browser without support for svg would not include it in the accept header. It may be unnccessary to mention this at all, since it is mentioned in the HTTP spec, but it could be mentioned that using the HTTP mechanisms for that wouldbe the reccomended approach (over proprietary query string parameters, or separate urls).
I had proposed that the OpenID Connect profile picture be returned using a base URL. The default size can be left undefined, but clients are able to optionally specify the desired size using an optional parameter. In order to avoid having to specify what "small/medium/large/x-large" means, we can do something like gravitar and let the client specify the size in pixels.
I agree, it seems much more reasonable to indicate a preferred image size in the request, rather than try to standardize what is medium and large.
I think it needs to be optional for the provider to adhere to the requested size, but strongly reccomended if the provider supports multiple sizes.
We could in example include one 'size' parameter and define it to:
- return an image which is preferrably as shallow as possible, but at least $size pixels wide, if possible.
or
- return an image which is as close to $size pixels wide as possible.
I think it would be easiest to ignore mentioning height or aspect ratio - what do you think?
Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110829/fd7bf6eb/attachment.html>
More information about the Openid-specs-ab
mailing list