IETF
CBOR
cbor@jabber.ietf.org
Tuesday, March 20, 2018< ^ >
Jeffpc has set the subject to: CBOR @ IETF 99 Prague - agenda: https://www.ietf.org/proceedings/99/agenda/agenda-99-cbor-01
Room Configuration
Room Occupants

GMT+0
[10:02:05] francesca joins the room
[10:03:20] francesca has set the subject to: CBOR @ IETF 101 London - https://datatracker.ietf.org/meeting/101/session/cbor
[10:31:39] francesca leaves the room
[11:26:01] francesca joins the room
[11:26:06] francesca leaves the room
[13:14:09] meetecho joins the room
[13:15:23] WOMrl6BW joins the room
[13:25:10] Ricardo Andreasen joins the room
[13:25:10] Renzo Navas joins the room
[13:25:13] Sean Leonard joins the room
[13:26:28] Sean Leonard leaves the room
[13:26:31] Sean Leonard joins the room
[13:26:40] zyxbac joins the room
[13:27:20] zyxbac joins the room
[13:27:57] Sean Leonard leaves the room
[13:27:59] Yoshiro Yoneya joins the room
[13:28:00] Sean Leonard joins the room
[13:30:29] Edward Lewis joins the room
[13:31:01] Thiago Macieira joins the room
[13:34:21] <meetecho> Do you need support from the AV team there?
[13:34:32] <meetecho> We see chairs tinkering with the projector
[13:35:14] jyasskin joins the room
[13:35:32] <meetecho> Ok, looks like they sorted it out
[13:36:04] Thiago Macieira leaves the room
[13:36:35] brong joins the room
[13:36:46] zyxbac leaves the room: unknown reason
[13:37:05] hildjj joins the room
[13:37:13] jimsch1 joins the room
[13:37:18] m&m joins the room
[13:37:33] <hildjj> carsten's USB-C to HDMI converter was bad, but someone else had one.
[13:37:36] <jimsch1> meetecho: The plain hdmi plug did not seem to work correclty
[13:37:51] <meetecho> jimsch1: got it (y)
[13:38:18] <jimsch1> If you want comments relayed to the mic, please be explicit by doing something like MIC: ....
[13:38:21] <meetecho> hildjj: thanks for the clarification!
[13:38:22] Michel Veillette joins the room
[13:38:52] francesca joins the room
[13:42:41] Thiago Macieira joins the room
[13:42:43] Thiago Macieira leaves the room
[13:42:49] Thiago Macieira joins the room
[13:44:51] Thiago Macieira leaves the room
[13:45:01] Thiago Macieira joins the room
[13:45:04] <hildjj> carsten said "it won't be shakespeare".  See RFC 6120 and 6121 for RFCs that *are* shakespeare.
[13:46:58] Thiago Macieira leaves the room
[13:47:08] Thiago Macieira joins the room
[13:50:30] <Sean Leonard> MIC: I want to express that I am opposed to introducing "cuts" into CDDL v1.0. Cuts transform a context-free grammar into a context-sensitive one. An alternative, "subsets" or "constraints", was sketched out in Singapore. From an editorial point, this is introducing new matter at the last minute when it needs to be fleshed out more over the coming months, i.e., after we get this version of CDDL out. (So basically it is similar to Jeffrey Yaskin's point: not well specified and also trying to do too much.)
[13:51:45] <Thiago Macieira> Are we supposed to see any slides?
[13:52:46] <francesca> Thiago yes, you don't see them? are you in meetecho?
[13:53:14] <meetecho> Slides should be up and running
[13:53:38] hildjj leaves the room
[13:53:40] <francesca> (we are on slide 10 of https://datatracker.ietf.org/meeting/101/materials/slides-101-cbor-consolidated-00.pdf)
[13:53:42] hildjj joins the room
[13:54:15] <meetecho> Thiago Macieira: I don't see any connection from you to get slides and video feed, only the audio connection, can you try rejoining?
[13:54:26] Sean Leonard leaves the room
[13:54:30] Sean Leonard joins the room
[13:56:23] <Sean Leonard> Mic: So the point is that you want to say "4 is text only, all other uints are anything else", right? So the slide says "* unit" and that means "* all uints except 4", right? What happens when later you want to say 5 is only a byte string? You have to put ? 5 : at the top, but you can't put it at the top, you are supposed to be putting it at the bottom...
[13:56:42] <jyasskin> What's the efficiency of the CDDL parser? O(#group-entries^2)? O(2^#group-entries)?
[13:56:46] <jyasskin> And do we care?
[13:57:36] <jyasskin> Sean: I don't understand "supposed to ber putting it at the bottom"
[13:57:39] <Sean Leonard> ...when you expand in subsequent revisions of the spec
[13:57:47] <Sean Leonard> by extending the group
[13:58:06] <Sean Leonard> (yeah, what jim schaad is saying)
[13:58:08] <jyasskin> Ah
[13:58:11] <Sean Leonard> (you can mic that)
[13:58:48] <jimsch1> Did I get the same as what you said
[13:58:57] <Sean Leonard> pretty much, jimsch. thanks!
[14:00:05] <Sean Leonard> the way that "constraints" work is that you say, with appropriate syntax: * unit -> any FIRST. Then in the subsequent parts of the spec, you identify specific instances of *uint => any. For example: "when uint is 4: text". "When uint is 5: byte string". (this is discussed in draft-seantek-constrained-abnf, for ABNF.)
[14:00:35] <francesca> is that mic, Sean?
[14:00:43] <Sean Leonard> yes, you can mic that
[14:00:51] <Sean Leonard> so MIC: [previous text]
[14:01:04] <Sean Leonard> the precise nature of the syntax requires a bit more fleshing out though
[14:02:05] Brad Biddle joins the room
[14:02:25] brong leaves the room: Stream reset by peer
[14:02:30] Brad Biddle leaves the room
[14:02:37] hildjj leaves the room
[14:05:03] hildjj joins the room
[14:08:46] <Thiago Macieira> Ok, half an hour later, after erloading, I see slides and video.
[14:09:02] <Thiago Macieira> No, I wasn't seeing any slides. Or replies.
[14:10:08] <francesca> sorry Thiago :/ we are still into CDDL, CBOR is coming in a couple of slides
[14:13:06] Michael Breuer joins the room
[14:15:10] gianluca capitani joins the room
[14:15:47] <Sean Leonard> MIC: I appreciate jyasskin's view on Appendix C vs the main document, but I see it the other way: since this is CDDL v1.0, it's better as-is. More formalism can come after we get something out there. So I agree more with Carsten on this point.
[14:16:34] <Sean Leonard> Mic: (Mainly, get something out, keep it informal, and point out that CDDL is subject to change in future revisions.)
[14:17:14] gianluca capitani leaves the room
[14:19:19] <Sean Leonard> Mic: what work?
[14:19:34] <Sean Leonard> (specifically what work, is what i'm asking)
[14:20:04] <Sean Leonard> (nevermind)
[14:21:18] <hildjj> Sean: we mostly ended up agreeing with you.  publish a 1.0, then start working on a -bis immediately that could incorporate a structural change.  carsten will at least make sure anything that isn't clear is made clear.
[14:21:28] <Sean Leonard> ok
[14:21:34] Thiago Macieira leaves the room
[14:21:43] <Sean Leonard> (not mic) It is worth adding explicit text to this cddl document that this is the "first iteration" or "first sketch" of this language, and that further revisions are expected to refine the language.
[14:22:07] <jimsch1> I doubt it, that is generally understood and normal processing.
[14:22:53] Thiago Macieira joins the room
[14:26:55] <Sean Leonard> It is worth pointing out that the integer vs. floating point issue has JavaScript/JSON implications
[14:27:12] <jyasskin> Sean: I *think* the draft points that out, but if not, I think 'yes'.
[14:28:25] <jimsch1> This is definitely done for JSON.  The JavaScript implication is what they are talking about now.
[14:28:35] <Sean Leonard> ok. Actually, I surmise that all JSON map items are strings, so 1 vs 1.0 isn't even a thing, they are all "1"
[14:28:55] <Sean Leonard> (map keys, not referring to values)
[14:29:01] <jimsch1> Yes but then the world of 1 vs "1" becomes fun.
[14:33:56] <Thiago Macieira> Tried speaking but didn't get any reaction, so writing here:
[14:33:57] <Sean Leonard> bignums: kind of Pythonic?
[14:34:04] <Thiago Macieira> bignums may have a long encoding on purpose
[14:34:07] <Thiago Macieira> leading zeroes
[14:34:35] <Sean Leonard> mic: leading zeroes (please mic Thiago's point)
[14:35:34] <francesca> Thiago didn't see anything happen in Meetecho
[14:36:05] <Sean Leonard> Mic (Sean): I guess the point is, to what extent is CBOR type & tag information supposed to be preserved when serializing between different implementations?
[14:36:21] <meetecho> Thiago Macieira: if you want to speak, you need to get in the virtual queue. There's a hand icon next to your name, if you joined as a participant. If observer, you need to switch to participant first.
[14:38:55] <francesca> i see you now thiago, i'll let you speak after joe :)
[14:39:38] <Sean Leonard> ...I feel that the way forward with bignums specifically, is to say that the length of the bignum is material, whereas the length of a major type 0 or 1 (integers) is not material
[14:40:29] <Sean Leonard> material = cannot canonicalize it to something that omits the material information.
[14:42:32] <francesca> jim are you relaying from Sean?
[14:43:09] <jimsch1> Not prefixed with mic:
[14:43:38] <Sean Leonard> see one message though:
[14:43:39] <francesca> a previous point was I think
[14:43:46] <Sean Leonard> Mic (Sean): I guess the point is, to what extent is CBOR type & tag information supposed to be preserved when serializing between different implementations?
[14:43:51] <jimsch1> sorry - missed that one
[14:44:41] <Sean Leonard> Mic: I think that is worth a separate document, which also may define c14ns. (But I agree with joe hildebrand, that an option is just to say no c14n)
[14:45:42] <jyasskin> Sean: the length of the bignum is *sometimes* material. Which is why I like having each specification that uses CBOR specify its own canonicalization.
[14:46:05] <jyasskin> I have no opinion about doing this in a separate document.
[14:46:06] <Thiago Macieira> FYI, my implementation of CBOR in Qt will decode a tag 1 (Unix time_t) to tag 0 (ISO date/time).
[14:46:40] <jyasskin> Thiago: And the extended generic data model now gives you permission to do that. 🙂
[14:47:03] <jyasskin> I wonder if crypto bignums should avoid the current bignum tag, for this reason.
[14:49:09] <jimsch1> Not sure, I don't remember how bignums are defined, but I thought it was tag(binary string) - that sounds exactly like what we want.
[14:49:28] <francesca> Thiago, I'll let you speak after Jeffrey
[14:51:00] <Sean Leonard> Mic: my first impression about this is that there is a big distinction between equivalence of data of major types (int 0x01 vs int 0x0001), and equivalence of data of tagged types (bignum h'01' !== int 0x01 due to bignum tag
[14:51:31] <jimsch1> Yeah, but Carstean does not believe that at all.  That is exactlky what I said.
[14:51:42] <Sean Leonard> I know, jim, I know
[14:52:21] <Sean Leonard> I do believe that the most "generic" encoders and decoders, should not have to delve into the semantics of major type 6 tags.
[14:53:20] <Sean Leonard> in contrast, the major generic encoders and decoders do have the major types (untagged) within their purview, such as, for example, the proper formatting of text strings (UTF-8)
[14:53:25] <Sean Leonard> UTF - 8
[14:54:45] <jimsch1> I would completely agree with that point of view.
[14:56:38] Renzo Navas leaves the room
[14:58:24] <Sean Leonard> how about a separate document: "The Challenges of Canonicalization: Some Guideposts for CBOR"?
[14:59:10] <jimsch1> s/Challenges/Extreme Peril/?
[14:59:35] <Sean Leonard> Trying to not be too judgmental ;-)
[14:59:52] <Sean Leonard> ...in the title anyway
[15:02:42] <Thiago Macieira> Can we move the guideposts?
[15:03:25] <hildjj> Thiago: for what?
[15:03:32] <Sean Leonard> why not, it makes the game more challenging :D
[15:05:01] <Thiago Macieira> As mentioned by email to Carsten and a few others: the *rows* may need work. I'll re-send to the list.
[15:05:05] Ricardo Andreasen leaves the room
[15:07:08] brong joins the room
[15:08:23] <Thiago Macieira> You may want to have a separtae tag for char, unsigned char and signed char.
[15:08:44] <jimsch1> Why would you not use ints for that?
[15:08:59] <Sean Leonard> THiago: why "char"? why not just two types: signed char and unsigned char?
[15:09:16] <Sean Leonard> also, I think int8 === char
[15:09:57] <Thiago Macieira> Because char can be unsigned on some architectures.
[15:10:05] <Thiago Macieira> For some reason I don't know, the C standard left that undefined.
[15:13:21] <jyasskin> Thiago: I would be sad if CBOR repeated C's mistake there.
[15:13:34] <Sean Leonard> +1 to jyasskin
[15:13:43] <Thiago Macieira> Fair enough.
[15:14:10] <jimsch1> CBOR does not have anything called a char.  It uses UTF-8 for characters, so the length is not set.  
[15:14:19] <Sean Leonard> Mic (or Chairs): What is the pending IANA registration?
[15:15:03] <jyasskin> The semantics would have to be that the signedness of the 'char' type depended on the parser, which isn't reasonable for a serialization format.
[15:16:29] <Sean Leonard> Mic: +1 to jimsch1's comment. Prefer 3-byte space. The technical question is: do we expect jroatch-tags to expand beyond the current tag registrations, such as 128-bit, 256-bit, etc.?
[15:17:31] <jimsch1> sean, if it did then a new tag range would be needed
[15:18:01] <Sean Leonard> If the answer is yes, 3+ -byte is obvious. if no, it's a bit more bikeshedding, I suppose...but still slightly in favor of 3-byte (from here)
[15:18:26] <Sean Leonard> jimsch1: yes, a new range, or just pre-register/reserve a larger tag range
[15:19:59] Pavan Yadav joins the room
[15:21:14] <Sean Leonard> can I respond to the RGB?
[15:21:19] <hildjj> y
[15:21:50] <Sean Leonard> Mic: about RGB. it's interesting, but I was recently thinking about High Dynamic Range (HDR). I think RGB is a bit more complicated in this day of 4K, HDR10, Dolby Vision, all that...probably needs some specialized data type(s)
[15:22:04] <Sean Leonard> which is to say, probably outside the purview of jroatch typed arrays
[15:22:15] <Sean Leonard> I agree that typed arrays should be worked on by the WG
[15:23:55] zyxbac leaves the room: offline
[15:24:02] m&m leaves the room: Disconnected: closed
[15:25:05] Michael Breuer leaves the room
[15:25:07] jimsch1 leaves the room
[15:25:07] hildjj leaves the room
[15:25:08] Thiago Macieira leaves the room
[15:25:19] Pavan Yadav leaves the room
[15:25:20] Michel Veillette leaves the room
[15:25:20] Sean Leonard leaves the room
[15:25:20] Edward Lewis leaves the room
[15:27:01] jyasskin leaves the room
[15:27:44] meetecho leaves the room
[15:28:58] brong leaves the room: Stream reset by peer
[15:35:17] jimsch1 joins the room
[15:36:01] jimsch1 leaves the room
[15:36:19] francesca leaves the room: unknown reason
[15:36:37] Yoshiro Yoneya leaves the room
[15:36:39] Yoshiro Yoneya joins the room
[15:39:59] WOMrl6BW leaves the room
[15:43:58] brong joins the room
[15:48:26] m&m joins the room
[15:48:35] Yoshiro Yoneya leaves the room
[15:48:36] m&m leaves the room
[15:59:04] jyasskin joins the room
[16:27:48] brong leaves the room
[17:00:15] hildjj joins the room
[17:04:51] hildjj joins the room
[17:05:08] hildjj leaves the room
[17:16:58] jyasskin leaves the room
[17:37:10] jyasskin joins the room
[17:58:08] hildjj leaves the room
[18:23:03] jyasskin leaves the room
[20:55:41] jeffpc joins the room
[21:51:40] jeffpc leaves the room
[22:04:04] jyasskin joins the room
Powered by ejabberd - robust, scalable and extensible XMPP server Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!