Re: [core] FW: Question on RFC 7252

[Carsten Bormann <[e-mail]>]

Hi Jim,

> 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.

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).

> 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

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.)

> 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?  

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
> 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.

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

Grüße, Carsten