-
Notifications
You must be signed in to change notification settings - Fork 4
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
Tags 37-39 are not "unassigned" #1
Comments
Hello Peter, thanks for the notification. gofast is still experimental, so it is not too late to change
protocol framing tags 6,7,8 need to be single byte because it is very among the {37,38,39,40,41,42} set of description tags,
Let me know what you think. It would be awesome if CBOR community would consider Thanks, |
The issue here is that the value space from 0-255 is very scarce, so they require stricter procedures for assigning codes to that space. For more information, see section 7.2 of RFC 7049 and section 4.1 of RFC 5226.
After your decision, I can say that:
You need to move tags 6 to 8 and tag 37 and 39 elsewhere in the space to avoid conflicts. If possible, you should also check whether any of the existing tags in the registry meet your needs, and merge certain new tags into one tag to avoid unnecessary tag codes. Visit http://www.iana.org/protocols/apply to apply to add new tags to the CBOR tag registry, and include the information requested in section 7.2 of RFC 7049 in the application. |
I guess I can finally make up my mind on this issue. It stems from the following
To keep the framing bytes constant at 4 bytes I have to use one of the Having said this, I will still keep this issue open so that we can track the If there are any immediate concerns please let me know. Thanks, |
http://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml#tags As I said before, you need to assign CBOR tags so they don't conflict with existing tags. I will discuss each in turn:
@cabo : Please give your thoughts. |
So why don't we write this protocol up and get a "specification required" assignment? I'm not so hot about the single-byte tags; we have precious few of them and would like to reserve them for very general, heavily used tags with short data items. I believe you would be very well served with the specification required tags. I don't understand tag 8 (current number) -- what is this being applied to? |
Following is the map from old-tags to new-tags: tag-37 -> tag-43 tag-38 -> tag-44 tag-39 -> tag-45 tag-40 -> tag-46 tag-41 -> tag-47 It doesn't have any impact in memory foot-print or performance. But breaks compatibility with older-version of gofast.
Thanks @peteroupc, @cabo. I have followed your suggestion regarding Tag-37 to Tag-41 (inclusive). |
Regarding Opaque-value: By design opaque value should be >= 256. These are ephimeral tag values |
@cabo question about Tag-8 made me to look into the end-packet framing.
|
Regarding Tags-6,7,8: After some experiments, found that the overhead of using gofast protocol to That leaves only one more technicality: Streaming messages Following is the byte-dump of gofast-frames, carrying a stream of 3 messages,
deciphering first frame:
Automatically second and third frames act as the second and third item of the deciphering the fourth frame end-packet:
So the fourth frame behaves as the fourth item in the indefinite array |
Please note that we are more or less building a protocol similar to HTTP-2 Gofast already supports HTTP functions like:
It would be nice if Gofast can retain Tag-6,7,8. That is, if we think |
I cannot really decode these messages. In particular, the fourth message ends in an ff that is not closing any indefinite header (9f, bf) in the same message. One very useful tool here is http://cbor.me — here you can paste messages in hex (commas are ignored) on the right side and use the arrow to decode them; the inverse direction also works. |
Concatenating all 4 gofast-frames and diagnostic o/p from http://cbor.me 55799([h'D93E815819D82BBFD82C1871D82D4E0000000000000006616161616161FF', 55799(7(h'D93E815819D82BBFD82C1871D82D4E0000000000000006616161616161FF')), 55799(7(h'D93E815819D82BBFD82C1871D82D4E0000000000000006616161616161FF')), 55799(8(h'D93E8140'))]) 0xff matches 0x9f from the first-frame. |
* End-packet payload shall be ZERO-length byte-string. * 0xff shall be matching 0x9f.
This implementation assigns tags 37-39 with different meanings than in the document http://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml#tags . Using these tags should be avoided, as CBOR data that makes use of them with the meanings other than specified in that document would make them less interoperable; instead, tags starting from 266 should be used; they're currently not assigned according to that document.
The text was updated successfully, but these errors were encountered: