decoding tagged cbor

[mischief]

hi, i noticed it's not very easy to decode an item that is tagged as CBOR (tag 55799).

here's a diff that (i think) will make it easier to tag items as cbor, and decode items tagged as CBOR.

diff --git a/cbor.lua b/cbor.lua
index 22a29ad..9c34b9a 100644
--- a/cbor.lua
+++ b/cbor.lua
@@ -784,12 +784,13 @@ TAG = setmetatable(

     -- =====================================================================

-    _magic_cbor = function()
-      return cbor_c.encode(0xC0,55799)
+    _magic_cbor = function(value,sref,stref)
+      return cbor_c.encode(0xC0,55799) .. encode(value,sref,stref)
     end,

-    [55799] = function(_,pos)
-      return '_magic_cbor',pos,'_magic_cbor'
+    [55799] = function(packet,pos,conv,ref)
+      local value,npos = decode(packet,pos,conv,ref)
+      return value,npos,'_magic_cbor'
     end,

     -- **********************************************************

[spc476]

The reason I did CBOR tag 55799 the way I did was due to this bit from RFC-7049 (section 2.4.5):

In many applications, it will be clear from the context that CBOR is being employed for encoding a data item. For instance, a specific protocol might specify the use of CBOR, or a media type is indicated that specifies its use. However, there may be applications where such context information is not available, such as when CBOR data is stored in a file and disambiguating metadata is not in use. Here, it may help to have some distinguishing characteristics for the data itself.

Tag 55799 is defined for this purpose. It does not impart any special semantics on the data item that follows; that is, the semantics of a data item tagged with tag 55799 is exactly identical to the semantics of the data item itself.

It adds no semantic meaning and is meant more for a magic value than anything else.

[mischief]

i understand that. however, without my change it is unclear how to:

• encode a data item with tag 55799
• decode a data item tagged as 55799

all of the other decoding functions in TAG table work this way, so why not for _magic_cbor too?

[spc476]

That's the way I wrote it, since tag 55799 has no semantic meaning other than itself. And here's code to encode and decode with that tag:

local cbor = require "org.conman.cbor"
local pre  = { 1 , 2 , 3 , 4 , 5 }
local raw  = cbor.TAG._magic_cbor() .. cbor.encode(pre)
local magic,pos = cbor.decode(raw)

if magic ~= '_magic_cbor' then
  print("error")
end

local post = cbor.decode(raw:sub(pos,-1))

[mischief]

you don't think this is a little better, to match the behavior of the other TAG types? if not, feel free to close this issue.

local cbor = require "org.conman.cbor"
local pre  = { 1 , 2 , 3 , 4 , 5 }
local raw = cbor.TAG._magic_cbor(pre)
local post, _, magic = cbor.decode(raw, 1)

[spc476]

I don't. Because the semantics don't exist past the tag itself, this is the only tag (as I interpret it) that can be immediately followed by another tag, say, #24, which tags the following binary string as CBOR data to be processed at a later time, or a Perl object (#26, an extension). The code you have returns the following item as _magic_cbor, which technically isn't correct.

Think of the tag _magic_cbor, the three bytes 0xD9, 0xD9, 0xF7, as a magic value marking CBOR data, much like the bytes 0x7F, 0x45, 0x4C, 0x46 as marking an ELF executable under Unix, 0x47, 0x49, 0x46, 0x38, 0x39, 0x61 marking a GIF or 0x89, 0x50, 0x4E, 0x47 a PNG.