Subject: [core] Preliminary feedback from ETSI CoAP#2 plugtest

From: Carsten Bormann <[email-masked]>
Date: Wed, 5 Dec 2012 07:54:30 +0100

ETSI was kind enough to provide some quick feedback from the CoAP#2 plugtest that took place in Sophia Antipolis last week.

I have put up the preliminary overview slides at:

http://svn.tools.ietf.org/svn/wg/core/Preliminary-Results-CoAP%232.pdf

As usual for an industrial interoperability testing event, the details are under NDA, but let me just summarize this as a pretty good success.
We managed to get 60 pairings (different clients with different servers) tested, and got some 97.8 % of the test cases run to be interoperable.

More directly influencing the work of this WG, there also have been some technical observations.
The preliminary write-up is at:

http://svn.tools.ietf.org/svn/wg/core/Preliminary-Technical-feedback-from-CoAP%232-Plugtest.pdf

As in the above: Please excuse any errors in this -- the emphasis was on speed of feedback, not on editorial perfection.

One item that became obvious in the testing was already picked up in Ticket #265:
http://trac.tools.ietf.org/wg/core/trac/ticket/265
Please have a look at the ETSI feedback document for some more technical background.

I haven't seen any feedback on #265 beyond the hallway discussions during the plug test.
I think it is obvious that the text about 2.03 needs to be clarified.
It is also pretty clear that we want to follow HTTPbis' lead about defining the term "selected representation".
Whether we want to allow ETag on 2.01, 2.02*), 2.04 maybe can be debated, but it seems to me this wouldn't impose any increased complexity on implementations:  Servers are in no way obliged to send these ETags (and certainly shouldn't be), and clients can ignore them.
So there seems to be little negative impact from allowing the ETags.
Finally, we may want to allow an ETag even on an error response such as 4.12; this may need a bit more discussion.

The other item highlighted in the technical feedback document is about the choice between confirmable and non-confirmable Observe notifications.  This may lead to some clarifications in Observe.  More directly influencing the impending WGLC on the core CoAP specification, we maybe should reconfirm whether section 5.2.3 does say all that it needs to say.

Many thanks to the plugtest participants, and particularly to Laurent Velez for organizing the event and documenting its results so quickly!

Grüße, Carsten

*) Yes, deleting a resource can make a default representation spring back, so for consistency we should allow ETags even there.