15, 2011 10:02 AM
*To:* oauth@ietf.org <mailto:oauth@ietf.org>
*Subject:* [OAUTH-WG] Issue 18: defining new response types
I agree that this functionality is needed. However, I believe its
current embodiment is overly restrictive. I would suggest changing
this text:
Only one response t
defining new response types
>
> ** **
>
> You can’t have it both way. Either it is a simple string comparison or it
> requires parsing of the string. The current prose is designed to offer a
> visual cue without making any code changes to how response types are
> compared. To
uth-boun...@ietf.org]> On
Behalf Of Mike Jones
Sent: Friday, July 15, 2011 10:02 AM
To: oauth@ietf.org<mailto:oauth@ietf.org>
Subject: [OAUTH-WG] Issue 18: defining new response types
I agree that this functionality is needed. However, I believe its current
embodiment is overly res
lf Of Mike
Jones
Sent: Friday, July 15, 2011 10:02 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Issue 18: defining new response types
I agree that this functionality is needed. However, I believe its current
embodiment is overly restrictive. I would suggest changing this text:
Only one response ty
list.
EHL
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike
Jones
Sent: Friday, July 15, 2011 10:02 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Issue 18: defining new response types
I agree that this functionality is needed. However, I believe its current
embodime
I agree that this functionality is needed. However, I believe its current
embodiment is overly restrictive. I would suggest changing this text:
Only one response type of each combination may be registered and used for
making requests. Composite response types are treated and compared in the sa
