Subject: Re: [core] #232: Clarify inclusion of Location options in a 2.01 (Created) response

From: "core issue tracker" <[email-masked]>
Date: Mon, 04 Jun 2012 08:55:34 -0000

#232: Clarify inclusion of Location options in a 2.01 (Created) response

Comment (by zach@…):

 Agreement in the May 16th interim meeting:

 MAY send a 2.01 Created response, aligning 5.10.8 and 5.8.2.

-- 
-----------------------------+-------------------------------------
 Reporter:  hartke@…         |       Owner:  draft-ietf-core-coap@…
     Type:  editorial        |      Status:  new
 Priority:  minor            |   Milestone:  post-WGLC-1
Component:  coap             |     Version:  coap-09
 Severity:  In WG Last Call  |  Resolution:
 Keywords:                   |
-----------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/232#comment:2>
core <http://tools.ietf.org/core/>

---

From: "core issue tracker" <[email-masked]>
Date: Mon, 11 Jun 2012 14:46:51 -0000

#choose ticket.new
  #when True
 Esko Dijk notes (msg03057l):

 Section 5.8.2.

   If a resource has been created on the server, a 2.01 (Created) response
 that includes the URI of the new resource in a sequence of  one or more
 Location-Path and/or Location-Query Options SHOULD be returned.

 While section 5.10.8 defines this optional:

   The two options MAY be included in a response to indicate the  location
 of a new resource created with POST.

 Should 5.8.2. refer to 5.10.8 to define the right behaviour (to avoid
 double definitions) ?
  #end
  #otherwise
    #if changes_body
Changes (by zach@…):

 * status:  new => closed
 * resolution:   => fixed

    #end
    #if changes_descr
      #if not changes_body and not change.comment and change.author
Description changed by zach@…:
      #end

--
    #end
    #if change.comment

Comment:

 Done in r692. 5.8.2 now reads:

 {{{
 5.8.2.  POST

    The POST method requests that the representation enclosed in the
    request be processed.  The actual function performed by the POST
    method is determined by the origin server and dependent on the target
    resource.  It usually results in a new resource being created or the
    target resource being updated.

    If a resource has been created on the server, a 2.01 (Created)
    response MAY be returned, which may include the URI of the new
    resource in a sequence of one or more Location-Path and/or Location-
    Query Options (Section 5.9.1.1 and Section 5.10.8).  If the POST
    succeeds but does not result in a new resource being created on the
    server, a 2.04 (Changed) response SHOULD be returned.  If the POST
    succeeds and results in the target resource being deleted, a 2.02
    (Deleted) response SHOULD be returned.

    POST is neither safe nor idempotent.
 }}}
    #end
  #end
#end

-- 
-----------------------------+-------------------------------------
 Reporter:  hartke@…         |       Owner:  draft-ietf-core-coap@…
     Type:  editorial        |      Status:  closed
 Priority:  minor            |   Milestone:  post-WGLC-1
Component:  coap             |     Version:  coap-09
 Severity:  In WG Last Call  |  Resolution:  fixed
 Keywords:                   |
-----------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/232#comment:3>
core <http://tools.ietf.org/core/>

---

From: "core issue tracker" <[email-masked]>
Date: Mon, 18 Jun 2012 10:44:30 -0000

Comment (by esko.dijk@…):

 Comment on the new text:

 the "may" in "may include the URI of the new" -> why not MAY ?

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/232#comment:4>
core <http://tools.ietf.org/core/>

---

From: Klaus Hartke <[email-masked]>
Date: Mon, 18 Jun 2012 13:01:01 +0200

>  the "may" in "may include the URI of the new" -> why not MAY ?

Probably because the authoritative MAY is in 5.10.8. Or because
RFC2119 actually doesn't require the keywords to be capitalized. But I
see no harm in replacing the "may" with a MAY.

I'm more worried about the first MAY; it sounds a bit like it's
optional to return a response at all...

Klaus

---

From: "Dijk, Esko" <[email-masked]>
Date: Mon, 18 Jun 2012 11:28:55 +0000

> RFC2119 actually doesn't require the keywords to be capitalized.
Well, but core-coap section 1.2 defines them capitalized so ... :)

> optional to return a response at all...
My feel here was that a server could typically respond 2.04 in this case, instead of 2.01.

Esko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Klaus Hartke
Sent: Monday 18 June 2012 13:01
To: [email-masked]
Subject: Re: [core] #232: Clarify inclusion of Location options in a 2.01 (Created) response

Esko Dijk wrote:
> Comment (by esko.dijk@...):
>
>  Comment on the new text:
>

Klaus
_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 18 Jun 2012 13:53:41 +0200

On Jun 18, 2012, at 13:01, Klaus Hartke wrote:

> Or because

Fixed that part (not the whole ticket) in [716].

Grüße, Carsten

---

From: Klaus Hartke <[email-masked]>
Date: Mon, 18 Jun 2012 14:00:12 +0200

> My feel here was that a server could typically respond 2.04 in this case, instead of 2.01.

For comparison, this is what httpbis [1] says:

   The action performed by the POST method might not result in a
   resource that can be identified by a URI.  In this case, either 200
   (OK) or 204 (No Content) is the appropriate response status code,
   depending on whether or not the response includes a representation
   that describes the result.

   If a resource has been created on the origin server, the response
   SHOULD be 201 (Created) and contain a representation which describes
   the status of the request and refers to the new resource, and a
   Location header field (see Section 10.5).

So translated to CoAP, this would mean that *if* a resource is
created, there MUST be a response, the response code SHOULD be 2.01
(Created), there SHOULD be a payload, and there SHOULD be a Location
Option. If the POST succeeds but does *not* result in a new resource,
there MUST be response, the response code SHOULD be 2.04 (Changed) and
there MAY be a payload.

I'm not sure why we should do this very differently...

Klaus

[1] http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-19#section-6.5

---

From: "Dijk, Esko" <[email-masked]>
Date: Mon, 18 Jun 2012 13:18:36 +0000

> I'm not sure why we should do this very differently...
Me neither, though there could be some resource-constraint reasons for not sending back the Location-* options.
But a SHOULD on returning 2.01 for created resources seems logical.

The core interim discussion record for #232:

  Change is ok. Discussion on the level of the requirement SHOULD, MAY or MUST.
  Carsten: Quality of Implementation SHOULD?
  Cullen: HTTP servers often don't return the location.
  -> MAY seems best for sending 2.01

Esko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Klaus Hartke
Sent: Monday 18 June 2012 14:00
To: [email-masked]
Subject: Re: [core] #232: Clarify inclusion of Location options in a 2.01 (Created) response

Klaus

---

From: Klaus Hartke <[email-masked]>
Date: Mon, 18 Jun 2012 16:30:25 +0200

> But a SHOULD on returning 2.01 for created resources seems logical.

Then a SHOULD for the inclusion of a location in a 2.01 (Created)
response seems appropriate: there could be some resource-constraint
reasons, but the implication that the client won't be able to discover
the location of the created resource must be understood and carefully
weighed before omitting the options.

>  -> MAY seems best for sending 2.01

So it seems the discussion was about whether the inclusion of the
Location-* Options in a 2.01 (Created) response should be a SHOULD,
MAY or MUST, but the decision made was about whether the response code
for a new resource being a 2.01 (Created) should be a SHOULD, MAY or
MUST.

I think we should undo the decision for MAY here. If a new resource
was created, the response SHOULD have a 2.01 (Created) response code.

Klaus

---

From: "core issue tracker" <[email-masked]>
Date: Mon, 18 Jun 2012 18:40:42 -0000

Changes (by hartke@…):

 * status:  closed => reopened
 * resolution:  fixed =>

Comment:

 This ticket is about whether the inclusion of the Location-* Options in a
 2.01 (Created) response should be a SHOULD (as stated in coap-09 section
 5.8.2.) or a MAY (as stated in coap-09 section 5.10.8.). This is also what
 was discussed at the interim, but for some reason it seems that the
 discussion concluded with the decision to make the return of a 2.01
 (Created) response a MAY. I've reverted the changes made in r692 for now.

     Type:  editorial        |      Status:  reopened

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/232#comment:5>
core <http://tools.ietf.org/core/>

---

From: "core issue tracker" <[email-masked]>
Date: Fri, 22 Jun 2012 19:05:38 -0000

Changes (by hartke@…):

 * status:  reopened => closed
 * resolution:   => fixed

Comment:

 Section 5.10.8 references Section 5.8.2 now.

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/232#comment:6>
core <http://tools.ietf.org/core/>