Subject: [core] Fwd: New Version Notification for draft-ietf-core-observe-01

From: Klaus Hartke <[email-masked]>
Date: Tue, 08 Feb 2011 03:18:37 +0100

A new version of draft-ietf-core-observe is now available:

 http://tools.ietf.org/id/draft-ietf-core-observe-01.txt

 All 15 tickets have been closed; see the change log in Appendix B
 for details. Almost all tickets were editorial: only one technical
 change was made to enable reordering detection (see Section 4.3).

 Feedback welcome.

 Klaus

 -------- Original Message --------
 Subject: New Version Notification for draft-ietf-core-observe-01
 Date: Mon,  7 Feb 2011 11:55:44 -0800 (PST)
 From: IETF I-D Submission Tool <[email-masked]>
 To: [email-masked]
 Cc: [email-masked]

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

 Filename:	 draft-ietf-core-observe
 Revision:	 01
 Title:		 Observing Resources in CoAP
 Creation_date:	 2011-02-07
 WG ID:		 core
 Number_of_pages: 19

 Abstract:
 CoAP is a RESTful application protocol for constrained nodes and
 networks.  The state of a resource on a CoAP server can change over
 time.  This specification provides a simple extension for CoAP that
 gives clients the ability to observe such changes.

 The IETF Secretariat.

---

From: "G. Clark" <[email-masked]>
Date: Tue, 8 Feb 2011 00:07:04 -0500

Two questions:

1) Max-Age is being removed completely, correct?

2) If yes to #1, should section 4.4 of the core-observe document be  
updated to remove references to the Max-Age option?

--Gilbert Clark

On Mon, 07 Feb 2011 21:18:37 -0500, Klaus Hartke <[email-masked]> wrote:

> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 8 Feb 2011 07:20:56 +0100

> 1) Max-Age is being removed completely, correct?

No, just the request option -- the response option is here to stay.

(Long answer: removing the request option was the consensus of the last webex call -- we still have to validate the ticket on the mailing list.  I haven't heard anyone suggesting to remove the response option yet.  Do you?  We should always be open to simplification requests.)

Gruesse, Carsten

---

From: "Clark, Gilbert" <[email-masked]>
Date: Wed, 9 Feb 2011 21:59:24 -0500

> No, just the request option -- the response option is here to stay.

Thanks for the clarification.
 
> (Long answer: removing the request option was the consensus of the last webex
> call -- we still have to validate the ticket on the mailing list.  I haven't
> heard anyone suggesting to remove the response option yet.  Do you?

The comment was meant to be editorial rather than a vote one way or the
other :) 

> We should always be open to simplification requests.)
> 
> Gruesse, Carsten

--Gilbert

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 16 Feb 2011 09:49:52 +0200

Hi Klaus,

I have read the draft and I have a couple of questions

3.1 Establishment

    A client registers itself with a resource by sending a GET request
    that includes a Lifetime Option.  (SeeSection 5  <http://tools.ietf.org/html/draft-ietf-core-observe-01#section-5>  for the option
    definition.)  When a server receives such a request, it satisfies the
    request as with a basic GET request and, upon success, establishes an
    observation relationship between the client and the target resource.

In this text, it seems that the server can not defer the response when 
receiving
a subscription; it has to provide immediately initial notification of 
current state.
What if the server does not have yet any value to send?

4. Notifications

  A client must be prepared to
    receive notifications before the initial response to a GET request,
    after an error notification or after the client has requested the
    server to end the observation relationship.

Not clear how a client can differentiate the initial response to a GET 
request
from the subsequent ones...
it will just discover ex-post that what it got before was a subsequent one,
isn't it?

4.2 Retransmission

    When a server is retransmitting a confirmable message with a
    notification, waiting for an acknowledgement, and wants to notify the
    client of a state change using a new confirmable message, it MUST
    stop retransmitting the old notification and MUST attempt to transmit
    the new notification with the number of attempts remaining from the
    old notification.  When the last attempt to retransmit a confirmable
    message with a notification for a resource times out, the observation
    relationship is ended.

not so sure that stop retransmitting the old notification is always the 
best thing to do
there can be situations where it is important for the client receive old 
notification as well

so my suggestion is to at least relax the MUST to a SHOULD

cheers
/Sal

-- 
Salvatore Loreto
www.sloreto.com

On 2/8/11 4:18 AM, Klaus Hartke wrote:
>   From: IETF I-D Submission Tool<[email-masked]>
>   To: [email-masked]
>   Cc: [email-masked]
>
>

---

From: Klaus Hartke <[email-masked]>
Date: Wed, 16 Feb 2011 18:05:02 +0100

Salvatore Loreto wrote:
>    that includes a Lifetime Option.  (See Section 5 for the option

The initial notification is just like the response to a normal GET
request. If the server can obtain the value immediately, it sends the
initial notification as immediate response to the GET request;
otherwise, it sends it as deferred response.

> it will just discover ex-post that what it got before was a subsequent one,

The client does not need to differentiate between the initial
notification and subsequent ones. If the server sends the initial
notification X and another notification Y shortly after, and the two
messages are reordered such that Y arrives before X, then the client
can safely take Y as initial notification and may ignore the contents
of X.

> not so sure that stop retransmitting the old notification is always the best
> thing to do

Stop retransmitting the old notification is in line with the objective
stated in 4.1. The goal is to supply the client with the current
resource state, not to inform it of all state changes. When a server
is in the process of supplying a client with the current resource
state, and the state of the resource changes, the old resource state
is no longer the current resource state, so it makes little sense to
keep attempting to deliver it.

Klaus

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 17 Feb 2011 09:26:57 +0200

Hi Klaus,

thanks for the answer,
see my comments/suggestions on line

cheers
/Sal

-- 
Salvatore Loreto
www.sloreto.com

> otherwise, it sends it as deferred response.
I am OK with the behavior,
my concern is about the fact that the text is not completely clear
",upon success" can be confused as I did with the 2.00 OK answer to the GET

> can safely take Y as initial notification and may ignore the contents
right, nothing to complain but the fact that in the text at moment seems 
that
the initial response has something different from the subsequent one

> resource state, not to inform it of all state changes.
that is certainly a goal, but should not be the only one
>   When a server
my objection is that there could be use cases where it is important to 
receive all the changes of status
so I would like to relax the MUST to at least SHOULD so to leave the 
freedom to the server to stop or not to retransmit
the old notifications