Subject: [core] #329: Ambiguity of Accept option still considered a problem

From: "core issue tracker" <[email-masked]>
Date: Tue, 28 May 2013 21:05:32 -0000

#329: Ambiguity of Accept option still considered a problem

 Pete Resnick notes (msg04531):

 Section 5.10.4

 I'm still worried about 5.10.4:

 The server SHOULD return the preferred Content-Format if available.  If
 the preferred Content-Format cannot be returned, then a 4.06 "Not
 Acceptable" SHOULD be sent as a response.

 The possibility that a server could potentially not send back a 4.06 seems
 really problematic from a client perspective. I have no way as a client to
 say, "I really can only accept format X, and if you can't make format X, I
 don't want something else", and I have no way to distinguish that from "I
 would prefer format X, but am willing to take whatever you can give me."
 For the former, I have to be prepared to throw things away. For the
 latter, I have to be willing to send two requests, the first with Accept
 (potentially getting back 4.06), and then a re-request without Accept.
 Which one of the above are current clients doing? If it's the former, then
 I suggest making this into an implementation note, and I would even
 consider getting rid of the 4.06 response code  for this use case, since
 it is nearly useless, and probably harmful. If it's the latter, then these
 SHOULDs ought to be MUSTs and the option should be critical so that
 clients can stop doing that.

 Carsten says:

 One thing we most likely don't want to change is that Accept is elective.
 So a client always has to be prepared to throw a response away.

 The only option to make Accept fully predictable is to get rid of 4.06.
 So far, we didn't really care that much about that full predictability.

 Should we go for it based on this DISCUSS?  (Accept also was the last
 option we changed...)

 Translated into HTTP terms, our Accept then always includes a

 ", *"

 at the end.

 We definitely need WG input on this one to make a decision.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  [email-masked]
  [email-masked]           |     Status:  new
     Type:  protocol     |  Milestone:  post-IESG-1
  defect                 |    Version:
 Priority:  major        |   Keywords:
Component:  coap         |
 Severity:  Submitted    |
  WG Document            |
-------------------------+-------------------------------------------------

Ticket URL: <http://tools.ietf.org/wg/core/trac/ticket/329>
core <http://tools.ietf.org/core/>

---

From: "Rahman, Akbar" <[email-masked]>
Date: Wed, 29 May 2013 09:31:18 -0400

Hi Carsten,

Regarding your question:

	The only option to make Accept fully predictable is to get rid
of 4.06.
 	So far, we didn't really care that much about that full
predictability.

 	Should we go for it based on this DISCUSS?  

It makes sense to me, so I am fine with this approach as a WG member.  

One clarification question though.  In HTTP is the behavior fully
equivalent (i.e. the HTTP version of Accept is fully predictable)?

Best Regards,

Akbar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
core issue tracker
Sent: Tuesday, May 28, 2013 5:06 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [core] #329: Ambiguity of Accept option still considered a
problem

 Section 5.10.4

 The possibility that a server could potentially not send back a 4.06
seems  really problematic from a client perspective. I have no way as a
client to  say, "I really can only accept format X, and if you can't
make format X, I  don't want something else", and I have no way to
distinguish that from "I  would prefer format X, but am willing to take
whatever you can give me."
 For the former, I have to be prepared to throw things away. For the
latter, I have to be willing to send two requests, the first with Accept
(potentially getting back 4.06), and then a re-request without Accept.
 Which one of the above are current clients doing? If it's the former,
then  I suggest making this into an implementation note, and I would
even  consider getting rid of the 4.06 response code  for this use case,
since  it is nearly useless, and probably harmful. If it's the latter,
then these  SHOULDs ought to be MUSTs and the option should be critical
so that  clients can stop doing that.

 Carsten says:

 One thing we most likely don't want to change is that Accept is
elective.
 So a client always has to be prepared to throw a response away.

 ", *"

 at the end.

-- 
-------------------------+----------------------------------------------
-------------------------+---
 Reporter:               |      Owner:
[email-masked]
  [email-masked]           |     Status:  new
     Type:  protocol     |  Milestone:  post-IESG-1
  defect                 |    Version:
 Priority:  major        |   Keywords:
Component:  coap         |
 Severity:  Submitted    |
  WG Document            |
-------------------------+----------------------------------------------
-------------------------+---

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

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 29 May 2013 16:14:34 +0200

> equivalent (i.e. the HTTP version of Accept is fully predictable)?

Good point!  Section 14.1 of RFC 2616 says:

   If an Accept header field is present,
   and if the server cannot send a response which is acceptable
   according to the combined Accept field value, then the server SHOULD
   send a 406 (not acceptable) response.

So this is a SHOULD (in HTTP, practically all header fields are the equivalent of our elective).

Section 5.3.2 in draft-ietf-httpbis-p2-semantics-22.txt weakens this to:

   If an Accept header field is
   present in a request and none of the available representations for
   the response have a media type that is listed as acceptable, the
   origin server MAY either honor the Accept header field by sending a
   406 (Not Acceptable) response or disregard the Accept header field by
   treating the response as if it is not subject to content negotiation.

In HTTP, the client can exclude the 406 case by adding "*" to the Accept header field.
Otherwise, the situation seems to be similar to our status quo. 

Grüße, Carsten

---

From: "core issue tracker" <[email-masked]>
Date: Wed, 29 May 2013 14:25:32 -0000

Comment (by [email-masked]):

 To recall: We changed Accept to be non-repeatable because otherwise
 it causes quite some problems with intermediaries and caching.

 I see Accept as "I want exactly this format." The client can pick from the
 "cf" list in the Link Format of the resource (or it is even predefined in
 some profile). The inefficient looping with different Accept options is
 only a fallback---and constrained devices usually do not support that many
 formats.

 With Accept being elective, I agree that 4.06 is kind of useless. The
 clients must provide code to check the actual Content-Format anyway and
 might even elide the check for 4.06. However, I think it has some value
 for debugging.

 I think we rather need a "the client MUST check if the Content-Format in
 the response matches the Accept value of the request."

 (Additional comment: I currently only return 4.06 when the resource
 actually supports multiple formats. When a resource only supports one, I
 ignore Accept and respond with that.)

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-core-
  [email-masked]           |  [email-masked]
     Type:  protocol     |      Status:  new
  defect                 |   Milestone:  post-IESG-1
 Priority:  major        |     Version:
Component:  coap         |  Resolution:
 Severity:  Submitted    |
  WG Document            |
 Keywords:               |
-------------------------+-------------------------------------------------

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