Subject: [core] -01 preview for implementors?

From: Zach Shelby <[email-masked]>
Date: Fri, 2 Jul 2010 15:59:03 +0300

We are getting pretty close to finishing up coap-01, I expect to submit this by next Wednesday. The plugfest in Maastricht is coming fast, so any implementors who need a preview before Wednesday to get started - just drop me an e-mail. People should be able to participate in the plugfest also remotely (IPv6, IPv4, Jabber), so not being there in person is no excuse!  

The minimum for participating is to implement the mandatory parts of coap-01 which have become even simpler compared to coap-00. The intention is also that the header and fields will not change after coap-01, so this will be a safe version to try out. Some of us will try to put servers on-line to test against as well soon after coap-01 is released. 

Zach  

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

---

From: [email-masked]
Date: Fri, 2 Jul 2010 16:02:02 -0400

Zach Shelby wrote on 07/02/2010 08:59:03:

> We are getting pretty close to finishing up coap-01, I expect to 
> submit this by next Wednesday. The plugfest in Maastricht is coming 
> fast, so any implementors who need a preview before Wednesday to get
> started - just drop me an e-mail. People should be able to 
> participate in the plugfest also remotely (IPv6, IPv4, Jabber), so 
> not being there in person is no excuse! 

I hope to have an implementation that will be available (via IPv4 only), 
but unfortunately I won't be there on Sunday and may or may not have 
internet access.  Meanwhile, I have been pestering Carsten's server to 
experiment with my client. 

Some observations/questions:
1. the content type in the Link Format is specified to be either 
media-type or media-code.  In the case that it's a media-code, it's the 
short encoding from section 11.2, but the interpretation is ambiguous.  Is 
it a raw 8-bit byte ("type=\x20") or some UTF-8 text encoding ("type=32")?
2. rather than assigning a new code for the compact accept option (in I-D.
draft-bormann-coap-misc ) could we not simply use option type 0 in a GET 
request and allow multiples?
3. generally speaking, do we wish to allow or prohibit duplicate options? 
If allow, what would, say multiple URL options mean in a GET?

Ed Beroset

---

From: Klaus Hartke <[email-masked]>
Date: Sun, 4 Jul 2010 18:46:01 +0200

> 3. generally speaking, do we wish to allow or prohibit duplicate options?

For any option that can have multiple values (Accept, If-None-Match,
...) the simplest solution is probably to allow duplicate options
instead of inventing a format for options with multiple values. On the
other hand, such a format would be trivial for options with values of
fixed width.

>  If allow, what would, say multiple URL options mean in a GET?

Multiple URL options do not have a lot of meaning in a GET, so I'd say
the superfluous options should be treated like any unknown or
malformed option in this case (see coap-misc-04, section 6.3).

Klaus