Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for decoding unassigned "simple values" (type 7) #228

Closed
davidlepilote opened this issue Nov 25, 2020 · 4 comments
Closed

Add support for decoding unassigned "simple values" (type 7) #228

davidlepilote opened this issue Nov 25, 2020 · 4 comments
Labels
Milestone

Comments

@davidlepilote
Copy link

As per the RFC-7049, it is possible to use the Major Type 7 (0b111) to pass values with no content :
https://tools.ietf.org/html/rfc7049#section-2.3

However, passing one of these value in a CBOR mapper ends with an exception. Here is a Kotlin sample to reproduce the exception :

fun main(args: Array<String>) {
    val cborMapper = ObjectMapper(CBORFactory())
    cborMapper.readValue(byteArrayOf(0b1110, 0b0001), object : TypeReference<Any>() {})
}

This throws the following exception :
Exception in thread "main" com.fasterxml.jackson.core.JsonParseException: Invalid CBOR value token (first byte): 0xe1

It should be possible to use these kinds of values, is there a possibility to solve this problem ?

Thanks

@cowtowncoder
Copy link
Member

Thank you for reporting this: I'll take a look soon to see what is going on.

One quick question: is the byteArrayOf() here producing one or two bytes? At first I thought it must be two, but based on other comments I guess it should be a single byte with value of 0xE1?

@davidlepilote
Copy link
Author

Hello,

Thank you for your prompt answer. You're completely right, I should have written byteArrayOf(0xE1.toByte()). The idea here is indeed to produce one byte of value 0xE1.

I started to write some code but it doesn't work as expected. I wanted to change how the CBORParser class handles tokens of Major Type 7 but didn't manage to output the right values.

@cowtowncoder
Copy link
Member

@davidlepilote Ok. Looks like there are undefined "simple values", meaning of which is specified somewhere else. Decoding part would not be too hard, but runs into one very specific conceptual problem -- how should these be exposed as JsonToken? It is not possible to simply skip them (for Objects it would require hiding the whole entry; for Arrays size would differ), and without knowing expected type cannot quite map them either.

I guess the obvious answer would be JsonToken.VALUE_EMBEDDED_OBJECT which is already used for format-specific types (most commonly binary data); and we could perhaps add simple CBORSimpleValue(int) container as value.
This would also be needed on generation side, probably via JsonGenerator.writeEmbeddedObject(Object), which could expect this container.

But one thing that I do not quite understand is this: I do not see any definitions for simple values beyond standard-specified ones, on:

https://en.wikipedia.org/wiki/CBOR#Simple_value

(in contrast to type tags, for which registrations exist)

So... is there some specific use case in existence?

@cowtowncoder cowtowncoder added 2.13 and removed 2.12 labels Nov 25, 2020
@cowtowncoder
Copy link
Member

Planning to add rudimentary support for 2.12, in which valid "simple values" are exposed as JsonToken.VALUE_NUMBER_INT; this is relatively easy to support.
But for 2.13 will likely want to change to exposes as JsonToken.VALUE_EMBEDDED_OBJECT, as mentioned earlier (could make configurable too, perhaps)

@cowtowncoder cowtowncoder changed the title [CBOR] Add support for Floating-Point Numbers and Values with No Content Add support for decoding unassigned "simple values" (type 7) Nov 28, 2020
@cowtowncoder cowtowncoder added 2.12 and removed 2.13 labels Nov 28, 2020
@cowtowncoder cowtowncoder added this to the 2.12.0 milestone Nov 28, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants