Subject: [core] Fwd: New Version Notification for draft-hartke-core-pending-02.txt

From: peter van der Stok <[email-masked]>
Date: Mon, 26 Feb 2018 11:54:19 +0100

Hi Core,

a new version of the pending draft is submitted.
The current version does not try to extend one already dedicated 
response code or create a new one.

Klaus and Peter

A new version of I-D, draft-hartke-core-pending-02.txt
has been successfully submitted by Klaus Hartke and posted to the
IETF repository.

Name:		draft-hartke-core-pending
Revision:	02
Title:		"Pending" Responses for the Constrained Application Protocol 
(CoAP)
Document date:	2018-02-26
Group:		Individual Submission
Pages:		6
URL:            
https://www.ietf.org/internet-drafts/draft-hartke-core-pending-02.txt
Status:         
https://datatracker.ietf.org/doc/draft-hartke-core-pending/
Htmlized:       https://tools.ietf.org/html/draft-hartke-core-pending-02
Htmlized:       
https://datatracker.ietf.org/doc/html/draft-hartke-core-pending-02
Diff:           
https://www.ietf.org/rfcdiff?url2=draft-hartke-core-pending-02

Abstract:
    This document proposes a new type of response for the Constrained
    Application Protocol (CoAP) called a "Pending" response.  A CoAP
    server can use a Pending response to indicate that it has accepted a
    request but has not yet started processing it or that processing the
    request will take longer than a client is typically willing to wait
    for a response.

Please note that it may take a couple of minutes from the time of 
submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 26 Feb 2018 12:01:21 +0100

On Feb 26, 2018, at 11:54, peter van der Stok <[email-masked]> wrote:
> 
> The current version does not try to extend one already dedicated response code or create a new one.

No, but the draft seems to bend the semantics of existing response codes?
I think that is mainly a problem with 2.02, which means the resource is gone, but in this case it isn’t really gone just yet?

I’d rather provide that information in the body (the actual media type behind the content-format needs to be defined, anyway).

Grüße, Carsten

---

From: Klaus Hartke <[email-masked]>
Date: Mon, 26 Feb 2018 12:16:01 +0100

> No, but the draft seems to bend the semantics of existing response codes?

Not really. Or, at least, it shouldn't, although it appears a bit like
it due to the renamed response codes.

The idea is just that the content-format encourages the client to
poll/observe until it gets another content-format.

This should work with unaware intermediaries; only the two ends need
to understand it.

> I think that is mainly a problem with 2.02, which means the resource is gone, but in this case it isn’t really gone just yet?

Good point. Maybe we should restrict it to GET, PUT, and POST?

> I’d rather provide that information in the body (the actual media type behind the content-format needs to be defined, anyway).

The content-format is defined to be absent or a human-readable
diagnostic message (second to last paragraph in Section 2). It might
be worth being able to include application-specific status
information, but I don't have a good idea yet how to indicate the
content-format of that.

Klaus