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

[peter van der Stok]

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

[Carsten Bormann]

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

[Klaus Hartke]

Post by Carsten Bormann

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?

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.

Post by Carsten Bormann
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?

Post by Carsten Bormann
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