Subject: [core] Human Friendly Format for CoAP Debugging, is there Something?

From: Patrick Barrett <[email-masked]>
Date: Tue, 21 Apr 2015 10:10:03 -0500

I've making myself some simple little tools for helping with some of
the development that I've been doing. So far I've just been using a
JSON representation of my own invention for displaying a coap message,
see an example on http://coap.herokuapp.com/, but even that I'm
feeling is a little verbose. Before I put too much effort into these
tools, I was wondering if there is any standard (or de facto standard)
way of completely representing a coap message in a way that is easy to
read and write for a human, but still possible to parse for a
computer.

-- 
Patrick Barrett  //  E X O S I T E  //  Minneapolis, MN  //  www.exosite.com

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 21 Apr 2015 17:26:23 +0200

Good question.  For CBOR, we had the wisdom of writing up a “diagnostic format” right into the RFC.
For CoAP, we didn’t, yet (and the examples in the various CoAP documents now look all different…).
Your JSON-style format looks a lot like the internal format coap.me uses (except that coap.me uses o256 format for some of the byte strings).  Maybe we should sit together and write something up?

What is everyone else using?

Grüße, Carsten

On 21 Apr 2015 at 17:10:45, Patrick Barrett ([email-masked]) wrote:

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

---

From: Olaf Bergmann <[email-masked]>
Date: Wed, 22 Apr 2015 09:48:07 +0200

> What is everyone else using?

libcoap's client uses a very minimalistic representation in debug mode:

v:1 t:0 tkl:0 c:1 id:14175 o: [ 3:'coap.me', 11:'.well-known', 11:'core' ]

And with data:

v:1 t:2 tkl:0 c:69 id:14175 o: [ 4:'\xDE\xEA\x9A\x3E\x0E\xDA\xC4\x9B', 12:'\x28', 23:'\x0B' ] d:</test>;rt="test";ct=0,</validate>;rt="validate";ct=0,</hello>;rt="Type1";ct=0;if="If1",</bl%C3%A5b%C3%A6rsyltet%C3%B8y>;rt="bl\xC3

A more readable (but not json-like bloated) format would be appreciated.

Grüße
Olaf

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 22 Apr 2015 10:57:24 +0200

Nice an concise.
It may be worth separating the message layer parts (t, mid) from the rr
layer parts (code, token, options, payload) -- that would make it easier
to skip the former for TCP.

> v:1 t:0 tkl:0 c:1 id:14175 o: [ 3:'coap.me', 11:'.well-known', 11:'core' ]

C-375f 0.01<> [3: coap.me, 11: .well-known, 11: core]

(t in one character, MID in hex, token is empty here but would be in hex
as well. Add quotes where needed.)

I'm not so sure about the option numbers -- many people have
internalized the numbers, and they are nicely compact.  But it is also
nice to have the computer do the looking up...
To keep conciseness, we could try to come up with canonical
two-character names for options, as in

 1: im  if_match
 3: uh  uri_host
 4: et  etag
 5: in  if_none_match
 6: ob  observe
 7: up  uri_port
 8: lp  location_path
11: up  uri_path
12: cf  content_format
14: ma  max_age
15: uq  uri_query
17: ac  accept
20: lq  location_query
23: b2  block2
27: b1  block1
28: s2  size2
35: pu  proxy_uri
39: ps  proxy_scheme
60: s1  size1

(New options would just be presented by their numbers.)

An even more concise representation (not always applicable) might be  to
reassemble the URI (eating up all the u? options above):

C-375f 0.01<> [//coap.me/.well-known/core, ac: 40]

(I have added a non-URI option to illustrate that case.)

Grüße, Carsten

---

From: Patrick Barrett <[email-masked]>
Date: Thu, 23 Apr 2015 10:17:16 -0500

I like that, seems nice and simple. A couple questions:

Overall I think that is a nice general format, but I'm not sure that I
love the two character names for the options. I can see it for the
header fields since there are so few of them and won't be
significantly changing in the future, but I think it would be worth
spelling out the actual option names.

I also would really like to not have any magic numbers. Obviously it
would be unavoidable in some cases where the program doesn't know
about new options/formats/whatever yet.

I'd like to suggest something like:

v:1 t:CON c:GET  i:55 t:0F3A [Uri-Path:'.well-known':'core']
v:1 t:CON c:POST i:37 t:C345 [Uri-Path:'led'] :: 'on'
v:1 t:CON c:POST i:42 t:45FF [Uri-Path:'binarything'
Content-Format:application/octet-stream] :: <<FF432A>>
v:1 t:CON c:0.07 i:F1 t:C345 [76:0]

The header stuff is key:value, the options are key:value0:...:valueN
(for repeatable options) inside [] followed by the optional payload
where "::" denotes there is a payload. The header stuff would have
what type the values are predefined then for payload and options
things in quotes would be a string and things in <<>> would be a hex
byte list.

If we don't like the key:value format for the header items, I could
see something like Carsten's suggestion of "C-375f 0.01<>", but that
that took me awhile to parse what it meant. I'm not sure what is
planned as far as the version if header fields change for the TCP and
other versions, but we might want to add a "C1:" to the front of that
format.

The more I think about it, the more I like Carsten's header format
since it's more concise. Merging my thoughts into that would be
something like:

C1: CON-F345 GET {0F3A} [Uri-Path:'.well-known':'core']
C1: ACK-A4C3 Content {B6} [] :: 'hello, world'

Thoughts?

---

From: Paul Duffy <[email-masked]>
Date: Thu, 23 Apr 2015 11:46:31 -0400

Is the Wireshark decoder of any use here?

---

From: Olaf Bergmann <[email-masked]>
Date: Thu, 23 Apr 2015 18:07:28 +0200

Patrick Barrett <[email-masked]> writes:

[...]
> The header stuff is key:value, the options are key:value0:...:valueN

[...]

> C1: ACK-A4C3 Content {B6} [] :: 'hello, world'

One thing we would have to define for this is escaping the ticks.
We could use the usual \x27 as in 

C1: CON-F345 GET {0F3A} [SomeOption:'custom opt with: \x27quotes\x27']

Grüße
Olaf