Subject: [core] WGLC draft-ietf-core-observe-11: Token lifetime

From: "Kovatsch Matthias" <[email-masked]>
Date: Mon, 21 Oct 2013 16:49:56 +0000

Dear list

With Observe, it becomes hard to decide when a Token can be re-used for a new request. The client extended the meaning of a Token to the server it subscribes with. The server will continue to use this Token until it removes the Observe relationship. Problem is, the client does not know when this will happen, since there is only garbage collection and no definite cancellation. An off-line discussion with Klaus also indicated that the client cannot expect the Token to be free again, when it RSTed a CON notification.

When a client is no longer interested in notifications, it can simply forget about the Observe relationship. However, it must somehow store the Token in a list of wasted ones, it is not allowed to re-use. Do we need a sophisticated time-based mechanism like for MIDs? Or is there a good way to give the full control of the Token back to the client?

A confirmed cancellation would also help with this issue...

Ciao
Matthias

---

From: "Peter A. Bigot" <[email-masked]>
Date: Thu, 24 Oct 2013 07:38:57 -0500

On 10/21/2013 11:49 AM, Kovatsch Matthias wrote:
> Dear list
>
> With Observe, it becomes hard to decide when a Token can be re-used
> for a new request. The client extended the meaning of a Token to the
> server it subscribes with. The server will continue to use this Token
> until it removes the Observe relationship. Problem is, the client
> does not know when this will happen, since there is only garbage
> collection and no definite cancellation. An off-line discussion with
> Klaus also indicated that the client cannot expect the Token to be
> free again, when it RSTed a CON notification.

Why not?  Is this because the RST might be lost?  Doesn't step 2 in
section 4.5 require the server to drop the observation in any situation
where it is not acknowledged by the final retransmission, in which case
the client can assume the server has completed the transaction
(releasing the token) at most EXCHANGE_LIFETIME after the client
received the first CON notification message?  Step 3 starts with "If the
entry is still in the list of observers", suggesting that the removal is
immediate.

> When a client is no longer interested in notifications, it can simply
> forget about the Observe relationship. However, it must somehow store
> the Token in a list of wasted ones, it is not allowed to re-use. Do
> we need a sophisticated time-based mechanism like for MIDs? Or is
> there a good way to give the full control of the Token back to the
> client?
>

I agree this is a significant weak point.  I think it should be
addressed in a wider context of what a REST transaction means in CoAP.
If that can be answered, then we know what the token lifetime is and
don't have to come up with ad hoc rules that apply only to observe.

Peter

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Fri, 25 Oct 2013 13:20:53 +0000

> > until it removes the Observe relationship. Problem is, the client does
> > not know when this will happen, since there is only garbage collection
> > and no definite cancellation. An off-line discussion with Klaus also
> > indicated that the client cannot expect the Token to be free again,
> > when it RSTed a CON notification.
> 
> Why not?  Is this because the RST might be lost?  Doesn't step 2 in section 4.5
> require the server to drop the observation in any situation where it is not
> acknowledged by the final retransmission, in which case the client can
> assume the server has completed the transaction (releasing the token) at
> most EXCHANGE_LIFETIME after the client received the first CON notification
> message?  Step 3 starts with "If the entry is still in the list of observers",
> suggesting that the removal is immediate.

You would need to add these timing requirements to the Token. The client needs an EXCHANGE_LIFETIME timeout before reusing the Token, instead of freeing it along with rejecting the notification.

---

From: "Peter A. Bigot" <[email-masked]>
Date: Fri, 25 Oct 2013 08:33:48 -0500

On 10/25/2013 08:20 AM, Kovatsch Matthias wrote:
>>> With Observe, it becomes hard to decide when a Token can be
>>> re-used for a new request. The client extended the meaning of a
>>> Token to the server it subscribes with. The server will continue
>>> to use this Token until it removes the Observe relationship.
>>> Problem is, the client does not know when this will happen, since
>>> there is only garbage collection and no definite cancellation. An
>>> off-line discussion with Klaus also indicated that the client
>>> cannot expect the Token to be free again, when it RSTed a CON
>>> notification.
>>
>> section 4.5 require the server to drop the observation in any
>> situation where it is not acknowledged by the final retransmission,
>> in which case the client can assume the server has completed the
>> transaction (releasing the token) at most EXCHANGE_LIFETIME after
>> the client received the first CON notification message?  Step 3
>> starts with "If the entry is still in the list of observers",
> You would need to add these timing requirements to the Token. The
> client needs an EXCHANGE_LIFETIME timeout before reusing the Token,
> instead of freeing it along with rejecting the notification.

OK, but we agree this does work, right?  I thought you/Klaus were 
implying the client could never take control of the token back after 
using it in an observe transaction.

I think the delay requirement is already there since the client can't 
know that the RST made it through, or which notification retransmission 
it got (so it has to be conservative in estimating how much longer the 
server might still treat the transaction as active).  It'd be nice if 
such derived requirements were made explicit, but CoAP specifications 
don't usually do that.

Peter

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Fri, 25 Oct 2013 13:49:15 +0000

> OK, but we agree this does work, right?  I thought you/Klaus were implying
> the client could never take control of the token back after using it in an
> observe transaction.

Well, I still believe we have a problem without an active cancellation, since the server starts to take control of the Token and the client cannot claim it back.

> I think the delay requirement is already there since the client can't know that
> the RST made it through, or which notification retransmission it got (so it has
> to be conservative in estimating how much longer the server might still treat
> the transaction as active).  It'd be nice if such derived requirements were
> made explicit, but CoAP specifications don't usually do that.

Retransmissions are filtered through the MID, thus a client can re-use the Token instantly. I see the Token exclusively on the request/response layer. When the client receives a response to a request with the same Token, this exchange is completed and the Token free again (all in line with Carsten's mail). Thus, my question, how the server should treat a new request with this Token, when it still has it in its relationship store. I would say the server is slave to the client, just like when mirroring the Token for normal requests: The server has to update the Observe relationship entries according to the request (i.e., remove it, if no Observe option, update the observed resource when the path differs, etc.).

Ciao
Matthias

---

From: "Peter A. Bigot" <[email-masked]>
Date: Fri, 25 Oct 2013 09:23:26 -0500

On 10/25/2013 08:49 AM, Kovatsch Matthias wrote:
>> implying the client could never take control of the token back
>> after using it in an observe transaction.
>
> Well, I still believe we have a problem without an active
> cancellation, since the server starts to take control of the Token
> and the client cannot claim it back.

Maybe we don't agree.  I think the client can claim it back as soon as 
it knows the "exchange"/"transaction" is complete, which is when the 
server has sent a confirmable notification and failed to receive an 
acknowledgement of it after all required retransmission 
(EXCHANGE_LIFETIME seconds).  I do think the process by which this is 
done is currently inadequate as the client can't initiate it, and may 
fail to detect it has happened, but it does exist; see below.

>> I think the delay requirement is already there since the client
>> can't know that the RST made it through, or which notification
>> retransmission it got (so it has to be conservative in estimating
>> how much longer the server might still treat the transaction as
>> active).  It'd be nice if such derived requirements were made
>> explicit, but CoAP specifications don't usually do that.
>
> Retransmissions are filtered through the MID, thus a client can
> re-use the Token instantly. I see the Token exclusively on the
> request/response layer. When the client receives a response to a
> request with the same Token, this exchange is completed and the Token
> free again (all in line with Carsten's mail).

Here's where I dislike Carsten's use of "exchange", which is fine in 
base CoAP for one request with one response but does not scale to either 
observe or block.

I think an "(observe) transaction" (to the server) comprises a client 
endpoint, a set of Uri-* options, and a token (other cache-key options 
may be present but I don't think they should identify the observe 
transaction, but rather be parameters to it).

The observe transaction begins when the client does the original GET 
with Observe and a specific Token.  It ends when the server completes 
sending the last response associated with that original GET: immediately 
if the server responds without an Observe token, or when the server 
removes the subscription from the list of observers.  Without your 
proposal (which I support, see below) that removal can only be 
influenced by the client when the server sends a confirmable 
notification, which can take up to 24 hours.  But if the client does 
receive such a notification it can ensure the transaction ends, and it 
can know an upper bound on how long it will be before the server has to 
completed it.  (Assuming it knows the server's EXCHANGE_LIFETIME.)

(And assuming the server is not entitled to self-create observers 
without an explicit request; otherwise it might start up again after a 
power cycle.)

  Thus, my question, how
> the server should treat a new request with this Token, when it still
> has it in its relationship store. I would say the server is slave to
> the client, just like when mirroring the Token for normal requests:
> The server has to update the Observe relationship entries according
> to the request (i.e., remove it, if no Observe option, update the
> observed resource when the path differs, etc.).

Yes: in my view a GET with the same Token and Uri-* options results in a 
modification of the existing transaction: renewing it if Observe is 
present, cancelling it if Observe is absent, potentially changing 
characteristics in other situations (e.g., if a cache-key option value 
changes).

Peter

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Fri, 25 Oct 2013 15:17:40 +0000

I think we talk about the same things and agree:

A CoAP exchange/transaction is active from the first request (the might be re-registration) until the last response (e.g., an error response without Observe option). Thus, the Token is in use as long as the Observe relationship exists. Even if the server reboots and forgets about it, the client considers it active until the Max-Age mechanism kicks in and refreshes or detects the loss of the relationship.

The exchange is also complete and the Token freed when a CON notification is rejected. Thanks to the MID deduplication even right after sending the first RST and not only after EXCHANGE_LIFETIME seconds.

But there is a problem that the client has to wait for this CON notification and cannot trigger it. Thus, we should have a client-initiated cancellation as well.

It is logical that a requests with a Token already in use is part of and modifies the corresponding exchange/transaction. Thus, we need to clarify for Observe what happens when the client sends a different request to the server using the same Token. I am in favor of:
- re-registration if with Observe option
- cancellation if without Observe option
- cancellation and new relationship if with Observe option, but with a different URI (the client has to sort out his mess...).

There were some objections that cancelling with a GET and thus retrieving a representation the client is not interested in anymore would not make sense. However, I see Observe built on top of GET, so we have an easy fallback to a normal GET in case the server does not support Observe. Thus, everything can/should happen through GET.

I hope I summarized comprehensibly :)
Ciao
Matthias

> -----Original Message-----
> From: Peter A. Bigot [mailto:[email-masked]]
> Sent: Freitag, 25. Oktober 2013 16:23
> To: Kovatsch Matthias; [email-masked]
> Subject: Re: [core] WGLC draft-ietf-core-observe-11: Token lifetime
> 
> > cancellation, since the server starts to take control of the Token and
> > the client cannot claim it back.
> 
> Maybe we don't agree.  I think the client can claim it back as soon as it knows
> the "exchange"/"transaction" is complete, which is when the server has sent
> a confirmable notification and failed to receive an acknowledgement of it
> after all required retransmission (EXCHANGE_LIFETIME seconds).  I do think
> the process by which this is done is currently inadequate as the client can't
> initiate it, and may fail to detect it has happened, but it does exist; see
> below.
> 
> >> know that the RST made it through, or which notification
> >> retransmission it got (so it has to be conservative in estimating how
> >> much longer the server might still treat the transaction as active).
> >> It'd be nice if such derived requirements were made explicit, but
> >> CoAP specifications don't usually do that.
> >
> > Retransmissions are filtered through the MID, thus a client can re-use
> > the Token instantly. I see the Token exclusively on the
> Here's where I dislike Carsten's use of "exchange", which is fine in base CoAP
> for one request with one response but does not scale to either observe or
> block.
> 
> I think an "(observe) transaction" (to the server) comprises a client endpoint,
> a set of Uri-* options, and a token (other cache-key options may be present
> but I don't think they should identify the observe transaction, but rather be
> parameters to it).
> 
> The observe transaction begins when the client does the original GET with
> Observe and a specific Token.  It ends when the server completes sending
> the last response associated with that original GET: immediately if the server
> responds without an Observe token, or when the server removes the
> subscription from the list of observers.  Without your proposal (which I
> support, see below) that removal can only be influenced by the client when
> the server sends a confirmable notification, which can take up to 24 hours.
> But if the client does receive such a notification it can ensure the transaction
> ends, and it can know an upper bound on how long it will be before the
> server has to completed it.  (Assuming it knows the server's
> EXCHANGE_LIFETIME.)
> 
> (And assuming the server is not entitled to self-create observers without an
> explicit request; otherwise it might start up again after a power cycle.)
> 
>   Thus, my question, how
> > The server has to update the Observe relationship entries according to
> > the request (i.e., remove it, if no Observe option, update the
> modification of the existing transaction: renewing it if Observe is present,
> cancelling it if Observe is absent, potentially changing characteristics in other
> situations (e.g., if a cache-key option value changes).
> 
> Peter

---

From: "Peter A. Bigot" <[email-masked]>
Date: Fri, 25 Oct 2013 10:49:49 -0500

On 10/25/2013 10:17 AM, Kovatsch Matthias wrote:
> A CoAP exchange/transaction is active from the first request (the
> might be re-registration) until the last response (e.g., an error
> response without Observe option). Thus, the Token is in use as long
> as the Observe relationship exists. Even if the server reboots and
> forgets about it, the client considers it active until the Max-Age
> mechanism kicks in and refreshes or detects the loss of the
> relationship.

Yes.

And in this case the server considers it active until something happens 
to cancel it, even if the client reboots and starts re-using the token.

> The exchange is also complete and the Token freed when a CON
> notification is rejected. Thanks to the MID deduplication even right
> after sending the first RST and not only after EXCHANGE_LIFETIME
> seconds.

Meh; maybe.  If the RST is lost the server might send the message again. 
  If the client implements deduplication (it's not required to), perhaps 
it's ok for the client to have already initiated a different transaction 
with the same Token.  Though if NSTART > 1 (or the network re-orders 
packets) there might be a NON notification with the same token still in 
the pipeline.

It might work, but it's pretty confusing and not obviously robust.  This 
is part of why I think we need a more refined concept of transaction and 
the generic steps that can be taken by a client or server to cancel one 
if necessary.  We should not be trying to address this solely from the 
perspective of observe.

>
> But there is a problem that the client has to wait for this CON
> notification and cannot trigger it. Thus, we should have a
> client-initiated cancellation as well.

I agree.

> It is logical that a requests with a Token already in use is part of
> and modifies the corresponding exchange/transaction. Thus, we need to
> clarify for Observe what happens when the client sends a different
> request to the server using the same Token. I am in favor of:

> - re-registration if with Observe option

Yes.

> - cancellation if without Observe option

Yes.

Note that with block notifications where only the first fragment appears 
as part of the observe transaction, we have not clearly addressed the 
mechanism by which a client initiates the block transfer to obtain the 
value associated with that particular notification, as it cannot include 
the corresponding Observe value in the request.  Perhaps it can't 
guarantee this (absent use of ETag).

> - cancellation and new relationship if with Observe option, but with a different URI (the client has to sort out his

Yes, but only because from the server perspective this is what would 
happen if the client rebooted, so there's server mess to be sorted out 
as well: in progress notification transmissions, etc.

Otherwise this is improper as it combines the cancellation of the first 
transaction with the creation of a new transaction.  Best to keep those 
concepts separate and say the client SHOULD cancel the previous 
transaction before re-using the same token in a new (observe or 
non-observe) transaction, as there may be a delay required before all 
parties can agree that a transaction has been cancelled.

>
> There were some objections that cancelling with a GET and thus
> retrieving a representation the client is not interested in anymore
> would not make sense. However, I see Observe built on top of GET, so
> we have an easy fallback to a normal GET in case the server does not
> support Observe. Thus, everything can/should happen through GET.

A few weeks ago we all agreed that GET with If-Match-None could serve as 
a HEAD that excluded a payload.  It would be good if this would be 
consistent with cancellation.

>
> I hope I summarized comprehensibly :) Ciao Matthias

I think so, if my replies don't reveal a misunderstanding on my part.

Peter

>
>
>> -----Original Message----- From: Peter A. Bigot
>> [mailto:[email-masked]] Sent: Freitag, 25. Oktober 2013 16:23 To:
>> Kovatsch Matthias; [email-masked] Subject: Re: [core] WGLC
>> draft-ietf-core-observe-11: Token lifetime
>>
>>>> OK, but we agree this does work, right?  I thought you/Klaus
>>>> were implying the client could never take control of the token
>>>> back after using it in an observe transaction.
>>>
>>> cancellation, since the server starts to take control of the
>>> Token and the client cannot claim it back.
>>
>> Maybe we don't agree.  I think the client can claim it back as soon
>> as it knows the "exchange"/"transaction" is complete, which is when
>> the server has sent a confirmable notification and failed to
>> receive an acknowledgement of it after all required retransmission
>> (EXCHANGE_LIFETIME seconds).  I do think the process by which this
>> is done is currently inadequate as the client can't initiate it,
>> and may fail to detect it has happened, but it does exist; see
>> below.
>>
>>>> retransmission it got (so it has to be conservative in
>>>> estimating how much longer the server might still treat the
>>>> transaction as active). It'd be nice if such derived
>>>> requirements were made explicit, but CoAP specifications don't
>>>> usually do that.
>>>
>>> request with the same Token, this exchange is completed and the
>>> Token free again (all in line with Carsten's mail).
>>
>> Here's where I dislike Carsten's use of "exchange", which is fine
>> in base CoAP for one request with one response but does not scale
>> to either observe or block.
>>
>> I think an "(observe) transaction" (to the server) comprises a
>> client endpoint, a set of Uri-* options, and a token (other
>> cache-key options may be present but I don't think they should
>> identify the observe transaction, but rather be parameters to it).
>>
>> The observe transaction begins when the client does the original
>> GET with Observe and a specific Token.  It ends when the server
>> completes sending the last response associated with that original
>> GET: immediately if the server responds without an Observe token,
>> or when the server removes the subscription from the list of
>> observers.  Without your proposal (which I support, see below) that
>> removal can only be influenced by the client when the server sends
>> a confirmable notification, which can take up to 24 hours. But if
>> the client does receive such a notification it can ensure the
>> transaction ends, and it can know an upper bound on how long it
>> will be before the server has to completed it.  (Assuming it knows
>> the server's EXCHANGE_LIFETIME.)
>>
>> without an explicit request; otherwise it might start up again
>> after a power cycle.)
>>
>> Thus, my question, how
>>> the server should treat a new request with this Token, when it
>>> still has it in its relationship store. I would say the server is
>>> slave to the client, just like when mirroring the Token for
>>> normal requests: The server has to update the Observe
>>> relationship entries according to the request (i.e., remove it,
>>> if no Observe option, update the observed resource when the path
>>> differs, etc.).
>>
>> Yes: in my view a GET with the same Token and Uri-* options results
>> in a modification of the existing transaction: renewing it if
>> Observe is present, cancelling it if Observe is absent, potentially
>> changing characteristics in other situations (e.g., if a cache-key
>> option value changes).
>>
>> Peter
>

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Fri, 25 Oct 2013 16:06:19 +0000

>   If the client implements deduplication (it's not required to), perhaps it's ok
> for the client to have already initiated a different transaction with the same
> Token.  Though if NSTART > 1 (or the network re-orders
> packets) there might be a NON notification with the same token still in the
> pipeline.

Okay, NON notifications with re-ordering are obviously a problem and we might need a cool-down time of NON_LIFETIME. This could be relaxed with a proper Token generator (I am not advocating re-using the same Token for everything, just that re-using should not break anything or that there are proper rules). A client without de-duplication should definitely put more effort into the choosing of Tokens. Tokens do not replace MID de-duplication, though!

[...]

> Note that with block notifications where only the first fragment appears as
> part of the observe transaction, we have not clearly addressed the
> mechanism by which a client initiates the block transfer to obtain the value
> associated with that particular notification, as it cannot include the
> corresponding Observe value in the request.  Perhaps it can't guarantee this
> (absent use of ETag).

This is a general problem of -block. I think the resource must implement this correctly, hence provide an ETag. Only if it knows that it does not change frequently, it might omit the ETag.

> > - cancellation and new relationship if with Observe option, but with a
> > different URI (the client has to sort out his mess...).
> 
> Yes, but only because from the server perspective this is what would happen
> if the client rebooted, so there's server mess to be sorted out as well: in
> progress notification transmissions, etc.
> 
> concepts separate and say the client SHOULD cancel the previous transaction
> before re-using the same token in a new (observe or
> non-observe) transaction, as there may be a delay required before all parties
> can agree that a transaction has been cancelled.

Indeed, the client should not (probably MUST NOT) do this. But there must be a defined behavior at the server in case the client does lose its state.

> A few weeks ago we all agreed that GET with If-Match-None could serve as a
> HEAD that excluded a payload.  It would be good if this would be consistent
> with cancellation.

Sounds good for this case.

Thanks for the discussion
Matthias

---

From: "Peter A. Bigot" <[email-masked]>
Date: Fri, 25 Oct 2013 13:39:50 -0500

On 10/25/2013 11:06 AM, Kovatsch Matthias wrote:
>>> notification is rejected. Thanks to the MID deduplication even
>>> right after sending the first RST and not only after
>>> EXCHANGE_LIFETIME seconds.
>>
>> Meh; maybe.  If the RST is lost the server might send the message
>> again. If the client implements deduplication (it's not required
>> to), perhaps it's ok for the client to have already initiated a
>> different transaction with the same Token.  Though if NSTART > 1
>> (or the network re-orders packets) there might be a NON
>> notification with the same token still in the pipeline.
>
> Okay, NON notifications with re-ordering are obviously a problem and
> we might need a cool-down time of NON_LIFETIME. This could be relaxed
> with a proper Token generator (I am not advocating re-using the same
> Token for everything, just that re-using should not break anything or
> that there are proper rules). A client without de-duplication should
> definitely put more effort into the choosing of Tokens. Tokens do not
> replace MID de-duplication, though!

No, they have nothing to do with MID de-duplication.

I suspect you're thinking of something here that I haven't understood, 
because I still don't see the relevance of MID de-duplication to this 
problem.  Unless it is that you mean the client can re-use the token 
immediately after the RST because any subsequent re-transmissions from 
the server (due to lost RST) would have the same MID and therefore be 
dropped by the client's message layer, so would not propagate up to the 
transaction layer where the client could mis-associate it with a 
previous transaction.  In this special case perhaps you could assume the 
part of the client that generates the token is aware of whether its 
message layer implements deduplication for the previous use of the 
token, though I wouldn't like to make that assumption that myself (I'm 
pretty strong on decoupling implementation features).

If that's what you meant, note that observe's message supersedure 
feature interferes with this dependence of MID de-duplication: if the 
RST to the first retransmission was lost and the resource value has 
changed, the server is currently permitted to send a new message (with a 
new message ID and new representation) in a subsequent retransmission. 
The client would need to be able to detect this and send another RST for 
that message, and so on until the last retransmission completes.

So again: it's much simpler to go with a general concept of "cancelled 
transaction" and specify how all parties can identify the time at which 
it's known there are no outstanding messages related to that 
transaction, so it is safe to re-use the token for a new transaction 
regardless of the method, options, etc. involved with the original or 
replacement transactions.

>> Note that with block notifications where only the first fragment
>> appears as part of the observe transaction, we have not clearly
>> addressed the mechanism by which a client initiates the block
>> transfer to obtain the value associated with that particular
>> notification, as it cannot include the corresponding Observe value
>> in the request.  Perhaps it can't guarantee this (absent use of
>> ETag).
>
> This is a general problem of -block. I think the resource must
> implement this correctly, hence provide an ETag. Only if it knows
> that it does not change frequently, it might omit the ETag.

If the resource is both large and not simply one of a small set of 
potential results, there may not be an ETag associated with the 
representation.

>>> - cancellation and new relationship if with Observe option, but
>>> with a different URI (the client has to sort out his mess...).
>>
>> Yes, but only because from the server perspective this is what
>> would happen if the client rebooted, so there's server mess to be
>> sorted out as well: in progress notification transmissions, etc.
>>
>> Otherwise this is improper as it combines the cancellation of the
>> first transaction with the creation of a new transaction.  Best to
>> keep those concepts separate and say the client SHOULD cancel the
>> previous transaction before re-using the same token in a new
>> (observe or non-observe) transaction, as there may be a delay
>> required before all parties can agree that a transaction has been
>> cancelled.
>
> Indeed, the client should not (probably MUST NOT) do this. But there
> must be a defined behavior at the server in case the client does lose
> its state.

Absolutely.  Again, true for block, groupcomm, observe, and any 
situation where a transaction comprises multiple exchanges (see my 
response to Carsten for terminology here).

>> A few weeks ago we all agreed that GET with If-Match-None could
>> serve as a HEAD that excluded a payload.  It would be good if this
>> would be consistent with cancellation.
>

Somebody needs to dig into the details and make sure it works out, though.

Peter

---

From: Klaus Hartke <[email-masked]>
Date: Fri, 25 Oct 2013 22:54:21 +0300

> Somebody needs to dig into the details and make sure it works out, though.

If I understand you two correctly, the idea is use a GET request with
the token of an ongoing observation and an If-Match-None option, but
without an Observe option, as a mechanism for a client to proactively
cancel an observation.

Besides it's pretty weird if a client has to ask a server "Please give
me a current representation of this resource. But without the
representation please. Oh, and, btw, I'm not interested in this
resource." when it actually wants to say "Hey! I'm not interested in
this resource any longer. Please cancel any further notifications.",
there is at least one case where this would be harmful: If the client
is observing the resource through an intermediary, the intermediary
might not have a current representation of the resource when the
request arrives. The server would then have to contact the origin
server (possibly through more intermediaries) just to get the current
representation that the client doesn't want but still requests. This
may even involve several lengthy separate responses if the origin
server cannot produce a current representation immediately.

Overloading the GET method with any semantics other than "Please give
me a current representation of this resource [and keep it updated over
time]." is a way in the wrong direction.

Best regards,
Klaus

---

From: "Peter A. Bigot" <[email-masked]>
Date: Fri, 25 Oct 2013 19:34:20 -0500

> without an Observe option, as a mechanism for a client to proactively

No.

The idea is use a GET request with the token of an ongoing observation 
but without an Observe option as a mechanism for a client to proactively 
cancel an observation.  Parallel to the way you use GET with an Observe 
option to create an observation associated with a token.

I just said that if somebody's knickers are in a twist about potentially 
receiving a representation that they don't want, they might be able to 
use an existing approach that inhibits the payload in a response to GET 
independently of other side-effects: viz, add an If-Match-None option. 
If you want the payload, or don't care about it, don't add If-Match-None.

In short, we're just defining useful semantics for a situation observe 
currently leaves under-specified.

Peter

---

From: Klaus Hartke <[email-masked]>
Date: Sat, 26 Oct 2013 05:21:14 +0300

>> without an Observe option, as a mechanism for a client to proactively

The rest of my mail applies regardless of whether If-None-Match is used or not.

Observing a resource is an activity between two hops. And unless the
next hop is the origin server, cancelling the activity should not
require contacting the origin server.

Klaus

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Sat, 26 Oct 2013 11:01:17 +0000

> If that's what you meant, note that observe's message supersedure feature
> interferes with this dependence of MID de-duplication: if the RST to the first
> retransmission was lost and the resource value has changed, the server is
> currently permitted to send a new message (with a new message ID and new
> representation) in a subsequent retransmission.

Nope, the server must re-use ongoing CON notifications for further changes and must await its outcome before sending new notifications with a new MID (4.5. Transmission). However, this requirement is not as clear anymore in observe-11, I think.

Ciao
Matthias

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Sat, 26 Oct 2013 11:18:36 +0000

> Observing a resource is an activity between two hops. And unless the next
> hop is the origin server, cancelling the activity should not require contacting
> the origin server.

But then I do not understand why Observe was built as option on top of GET in the first place when "overloading" the method is the wrong direction and there are such problems along intermediaries. Then a new method (or two for cancellation as well) might have been better? An OBSERVE method could then could also have a payload to configure the observe relationship, which could also ease bindings for M2M standards that build on CoAP.

I do not see the problem of retrieving one more representation compared to continued notifications for the next 24 hours...

Ciao
Matthias

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 26 Oct 2013 13:29:06 +0200

On 26 Oct 2013, at 13:18, Kovatsch Matthias <[email-masked]> wrote:

> But then I do not understand why Observe was built as option on top of GET in the first place

You know that, but just to answer the question for the potential benefit of others on the list:

Observe is an “Option” in the true sense of the word.
You ask a server for a representation, and add “by the way, it would be nice if you could keep me posted on updates”.
The server can consent (send back an Observe option in the response) or ignore.
(Observe is elective, so servers that don’t know about Observe will automatically choose to ignore).

All this works well because when you start an observation, you are really interested in the representation.
(Now I do know some use cases where you *are* only interested in changes to the representation, the “edge-triggered” case.  It is a matter of REST API design to turn edge-triggered into level-triggered.)

> I do not see the problem of retrieving one more representation compared to continued notifications for the next 24 hours...

It is indeed probably more of a cognitive-dissonance than a real-world problem.
If-No-Match just isn’t strong enough to get rid of this side effect, and the whole point here is we don’t want to invent another option (or option value).  Or maybe we do (but that should be well justified).

Grüße, Carsten

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Sat, 26 Oct 2013 11:35:20 +0000

> You know that, but just to answer the question for the potential benefit of

Yes, sorry, please excuse this unexplained rhetorical question.
I am just confused by this radical conclusion about overloading GET at this stage of the document.

Ciao
Matthias

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 26 Oct 2013 13:36:10 +0200

> When a client is no longer interested in notifications, it can simply forget about the Observe relationship. However, it must somehow store the Token in a list of wasted ones, it is not allowed to…

The current discussion seems to be about whether we want to actively encourage client to modify the exchange identified by an active token (here: cancel the observation).

I’m also interested in the original question: What do we have to say about the server experiencing a client (inadvertently or intentionally — the server can’t find that out) using an active token for a new exchange?
(Where newness is measured in any difference in method, cache-key options, or payload.)

1) Do we place any explicit requirements on the server here?

2) Are these requirements powerful enough to make reuse of active tokens a generally acceptable technique?  (Of course, this will only ever be useful if the client does not need the response or can disambiguate it between the old and the new exchange.)

Grüße, Carsten

---

From: "Peter A. Bigot" <[email-masked]>
Date: Sat, 26 Oct 2013 07:01:09 -0500

On 10/26/2013 06:01 AM, Kovatsch Matthias wrote:
>> feature interferes with this dependence of MID de-duplication: if
>> the RST to the first retransmission was lost and the resource value
>> has changed, the server is currently permitted to send a new
>> message (with a new message ID and new representation) in a
>> subsequent retransmission.
>
> Nope, the server must re-use ongoing CON notifications for further
> changes and must await its outcome before sending new notifications
> with a new MID (4.5. Transmission). However, this requirement is not
> as clear anymore in observe-11, I think.

Ah.  I guess that makes sense.  In the huge exchange culminating in 
http://www.ietf.org/mail-archive/web/core/current/msg04871.html I 
thought the conclusion was the MID did have to change when new data was 
transmitted.  Apparently my "obvious choice" (MID must change) was the 
wrong choice: going back and re-reading Carsten's mail that I was 
replying to, I guess he was hinting that this is a situation where it 
doesn't matter whether the client receives the new or old notification, 
so it's ok to re-use the MID for new content.

And yet again my concept of a confirmable message doesn't hold up to 
what CoAP wants to do with it.

Peter