Subject: [core] FW: Question on RFC 7252

From: "Jim Schaad" <[email-masked]>
Date: Wed, 3 Feb 2016 23:19:57 -0800

In section 2.2, these is discussion dealing with figure 5 about how to deal
with the case where a server can perform an operation, but it may take a
while to do and it does not want the client to continually send it messages
or time out waiting for a response.  The solution presented requires that a
token be present in the original request so that it can be tied to the
eventual response message. There does not appear to be any text dealing with
the case of a token not being present.

What is the proper response to say - ask again but make sure there is a
token in the request this time?  One could start the request processing and
respond with a 5.03 - service unavailable and an estimate of how long it
will take to complete the request but that seems wrong some how
 
What is the correct response to give if the separate message cannot be sent
anytime soon because the server already has a message in its cache with the
message id of the original request?  I am assuming, and believe that the
text in section 4.4 says that messages ids must be unique for the sender to
a specific address so the changes are low unless the server is using a hit
cache for multiple recipients.

Jim

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 04 Feb 2016 09:22:26 +0100

Hi Jim,

> the case of a token not being present.

There is always a token present (it may be zero-length, but an empty
token is still a token that is distinguishable from all other tokens).

> will take to complete the request but that seems wrong some how

That kind of response is different from a separate response as discussed
here and in section 5.2.2.  It may be quite appropriate, e.g. if the
server simply cannot keep request state for the time that it needs to be
able to prepare a response.  (I think you are aware that section 5.9.3.4
suggests using max-age for indicating when a new request should be
attempted.)

> message id of the original request?  

Not sure I can parse this.  If the server already has a (request?)
message in its cache with the message id of the original request, it
simply repeats the response it already sent.

> I am assuming, and believe that the

Message-IDs are per endpoint (peer endpoint in case of receiving a
CON/NON or sending an ACK/RST).

Grüße, Carsten