Thanks Justin And for a small clarification, Does the resource set description sent with a HTTP PUT only include the attributes to updated or the whole resource set description of the resource set? On Thu, Jul 16, 2015, 5:28 PM Justin Richer wrote:

You're correct, the example is wrong, and the normative text is ambiguous as it doesn't specify a response code. We implemented this as a 200. Additionally, we return the full entity on update since the text says the response "must include the _id" but doesn't specify whether or not to include anything else:

https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/blob/ma...

I'd file a new bug.

-- Justin

On 7/15/2015 9:30 PM, Farazath Ahamed wrote:

Hi,

The method described in the spec to update Resource Set descriptions[1] is supposed to return a HTTP 204 including the _id value of the successfully updated resource set description.

but the HTTP Status Code Definition for 204 says,

The 204 response MUST NOT include a message-body, and thus is always terminated by the first empty line after the header fields. Therefore is it correct to include a body in a 204. Is it possible to do that? Am I missing a trick here?

[1] https://docs.kantarainitiative.org/uma/draft-oauth-resource-reg.html#rfc.sec...

Thanks, --

*A.Farasath Ahamed*

Undergraduate | Department of Computer Science and Engineering,University of Moratuwa Article Writer | MoraSpirit Mobile: +94 777 603 866

Blog: http://thepseudocode.blogspot.com E-Mail: mefarazath@gmail.com

You’re correct, a PUT is a full replace. (Way back when, I think we discussed including a PATCH method too, but discarded it as too complex.) The spec isn’t ambiguous because PUT means full replacement (here’s a discussion http://stackoverflow.com/questions/19732423/why-isnt-http-put-allowed-to-do-... :-), but it wouldn’t hurt to clarify in belt-and-suspenders fashion if someone wants to put in an issue about it. Eve

On 16 Jul 2015, at 5:07 AM, Justin Richer wrote:

I believe it's supposed to send all the attributes to comply with common RESTful design (a PUT is a full replace, a PATCH would be a partial update), though the spec is also ambiguous about that.

-- Justin

On 7/16/2015 8:06 AM, Farazath Ahamed wrote:

...

Thanks Justin

And for a small clarification,

Does the resource set description sent with a HTTP PUT only include the attributes to updated or the whole resource set description of the resource set?

On Thu, Jul 16, 2015, 5:28 PM Justin Richer < mailto:jricher@mit.edujricher@mit.edu mailto:jricher@mit.edu> wrote: You're correct, the example is wrong, and the normative text is ambiguous as it doesn't specify a response code. We implemented this as a 200. Additionally, we return the full entity on update since the text says the response "must include the _id" but doesn't specify whether or not to include anything else:

https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/blob/ma... https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/blob/ma...

I'd file a new bug.

-- Justin

On 7/15/2015 9:30 PM, Farazath Ahamed wrote:

...

Hi,

The method described in the spec to update Resource Set descriptions[1] is supposed to return a HTTP 204 including the _id value of the successfully updated resource set description.

but the HTTP Status Code Definition for 204 says, The 204 response MUST NOT include a message-body, and thus is always terminated by the first empty line after the header fields.

Therefore is it correct to include a body in a 204. Is it possible to do that? Am I missing a trick here?

...

[1] https://docs.kantarainitiative.org/uma/draft-oauth-resource-reg.html#rfc.sec... https://docs.kantarainitiative.org/uma/draft-oauth-resource-reg.html#rfc.sec...

Thanks, --

...

A.Farasath Ahamed

...

Undergraduate | Department of Computer Science and Engineering,University of Moratuwa Article Writer | MoraSpirit Mobile: +94 777 603 866

...

Blog: http://thepseudocode.blogspot.com http://thepseudocode.blogspot.com/ E-Mail: mailto:mefarazath@gmail.commefarazath@gmail.com mailto:mefarazath@gmail.com

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com

Eve, And what about the response to an update? We can't send the 204 with a body right? On Sun, Jul 19, 2015, 3:53 PM Justin Richer wrote:

“PUT” only “means full replace” in the context of a well-defined specification that follows RESTful principles — but you could easily use it to mean whatever you want (and I’ve seen it done!). It’s much better in a spec to say exactly what it does and not assume.

— Justin

On Jul 19, 2015, at 5:15 AM, Eve Maler wrote:

You’re correct, a PUT is a full replace. (Way back when, I think we discussed including a PATCH method too, but discarded it as too complex.) The spec isn’t ambiguous because PUT means full replacement (here’s a discussion http://stackoverflow.com/questions/19732423/why-isnt-http-put-allowed-to-do-... :-), but it wouldn’t hurt to clarify in belt-and-suspenders fashion if someone wants to put in an issue about it.

Eve

On 16 Jul 2015, at 5:07 AM, Justin Richer wrote:

I believe it's supposed to send all the attributes to comply with common RESTful design (a PUT is a full replace, a PATCH would be a partial update), though the spec is also ambiguous about that.

-- Justin

On 7/16/2015 8:06 AM, Farazath Ahamed wrote:

Thanks Justin

And for a small clarification,

Does the resource set description sent with a HTTP PUT only include the attributes to updated or the whole resource set description of the resource set?

On Thu, Jul 16, 2015, 5:28 PM Justin Richer < jricher@mit.edu> wrote:

...

You're correct, the example is wrong, and the normative text is ambiguous as it doesn't specify a response code. We implemented this as a 200. Additionally, we return the full entity on update since the text says the response "must include the _id" but doesn't specify whether or not to include anything else:

https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/blob/ma...

I'd file a new bug.

-- Justin

On 7/15/2015 9:30 PM, Farazath Ahamed wrote:

Hi,

The method described in the spec to update Resource Set descriptions[1] is supposed to return a HTTP 204 including the _id value of the successfully updated resource set description.

but the HTTP Status Code Definition for 204 says,

The 204 response MUST NOT include a message-body, and thus is always terminated by the first empty line after the header fields. Therefore is it correct to include a body in a 204. Is it possible to do that? Am I missing a trick here?

[1] https://docs.kantarainitiative.org/uma/draft-oauth-resource-reg.html#rfc.sec...

Thanks, --

*A.Farasath Ahamed*

Undergraduate | Department of Computer Science and Engineering,University of Moratuwa Article Writer | MoraSpirit Mobile: +94 777 603 866

Blog: http://thepseudocode.blogspot.com E-Mail: mefarazath@gmail.com

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com

Thanks Eve Looks like i had the copy of an old version which i seemed to have saved locally :) The new one responds to the PUT with a 200 OK :) On Sun, Jul 19, 2015 at 11:53 PM, Eve Maler wrote:

(Yikes, you’ve seen PUT used for partial replace? That’s…horrible. I’ve never seen that myself. We should definitely clarify, then. We do have a design principle that’s explicit about striving for RESTfulness.)

Farazath, I suspect you may be looking at an old draft version of the RSR spec if you’re seeing a 204 on an example of PUT. I’m only seeing it in the example in the final Recommendation version of RSR Sec 2.3.4 for Delete, not RSR Sec 2.3.3 for Update or anywhere else (Kantara Recommendation https://docs.kantarainitiative.org/uma/rec-oauth-resource-reg.html, IETF I-D https://tools.ietf.org/html/draft-hardjono-oauth-resource-reg-06).

BTW, I have a goal — if my jet lag allows — to add spec links and quotes to comments on the new GitHub issues by tonight, in order to assist with any spec interpretation questions where possible. If anyone else has thoughts/opinions/implementation experience, it would be great if you could do that in the coming week, as the WG leadership team will be presenting an analysis approach for assigning issue priorities and milestones on the next call.

Eve

On 19 Jul 2015, at 3:56 AM, Farazath Ahamed wrote:

Eve, And what about the response to an update? We can't send the 204 with a body right?

On Sun, Jul 19, 2015, 3:53 PM Justin Richer wrote:

...

“PUT” only “means full replace” in the context of a well-defined specification that follows RESTful principles — but you could easily use it to mean whatever you want (and I’ve seen it done!). It’s much better in a spec to say exactly what it does and not assume.

— Justin

On Jul 19, 2015, at 5:15 AM, Eve Maler wrote:

You’re correct, a PUT is a full replace. (Way back when, I think we discussed including a PATCH method too, but discarded it as too complex.) The spec isn’t ambiguous because PUT means full replacement (here’s a discussion http://stackoverflow.com/questions/19732423/why-isnt-http-put-allowed-to-do-... :-), but it wouldn’t hurt to clarify in belt-and-suspenders fashion if someone wants to put in an issue about it.

Eve

On 16 Jul 2015, at 5:07 AM, Justin Richer wrote:

I believe it's supposed to send all the attributes to comply with common RESTful design (a PUT is a full replace, a PATCH would be a partial update), though the spec is also ambiguous about that.

-- Justin

On 7/16/2015 8:06 AM, Farazath Ahamed wrote:

Thanks Justin

And for a small clarification,

Does the resource set description sent with a HTTP PUT only include the attributes to updated or the whole resource set description of the resource set?

On Thu, Jul 16, 2015, 5:28 PM Justin Richer < jricher@mit.edu> wrote:

...

You're correct, the example is wrong, and the normative text is ambiguous as it doesn't specify a response code. We implemented this as a 200. Additionally, we return the full entity on update since the text says the response "must include the _id" but doesn't specify whether or not to include anything else:

https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/blob/ma...

I'd file a new bug.

-- Justin

On 7/15/2015 9:30 PM, Farazath Ahamed wrote:

Hi,

The method described in the spec to update Resource Set descriptions[1] is supposed to return a HTTP 204 including the _id value of the successfully updated resource set description.

but the HTTP Status Code Definition for 204 says,

The 204 response MUST NOT include a message-body, and thus is always terminated by the first empty line after the header fields. Therefore is it correct to include a body in a 204. Is it possible to do that? Am I missing a trick here?

[1] https://docs.kantarainitiative.org/uma/draft-oauth-resource-reg.html#rfc.sec...

Thanks, --

*A.Farasath Ahamed*

Undergraduate | Department of Computer Science and Engineering,University of Moratuwa Article Writer | MoraSpirit Mobile: +94 777 603 866

Blog: http://thepseudocode.blogspot.com E-Mail: mefarazath@gmail.com

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com

Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com

-- *A.Farasath Ahamed* Undergraduate | Department of Computer Science and Engineering,University of Moratuwa Article Writer | MoraSpirit Mobile: +94 777 603 866 Blog: http://thepseudocode.blogspot.com E-Mail: mefarazath@gmail.com