Internet Engineering Task Force Interim Meetings, 13 Jul 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF-CBOR-20220713-1400

Description

CBOR meeting session at IETF
2022/07/13 1400

https://datatracker.ietf.org/meeting//proceedings/

A

So I think I will wait till about two after the hour.

B

Microphone check anyone out there live, I can hear you and I can hear you.

C

That's the important part.

B

I have a conflicting meeting um and so I'll just listen um and carson. I will get back to you on that uh expert review on the join proxy today.

C

Great. Thank you.

A

And I think it is time to start we have a few more people, so welcome to the uh apparently the 12th seaborn interim meeting of the year um karsten we'll start with you or uh oh well. First, we have, I guess: uh monaco, uh as usual, you're gonna, be our notetaker.

A

Yeah, I see he's listed on there good thanks again, marco, as always, uh karsten off to you.

C

Oh, I am already unused yes confusing. I was looking how to unmute myself and I already was on youtube. Okay, thank you. um So this is a midsummer meeting, it's too bad! That christian can't be here, because he had most of the comments that I reacted to. So I think we have four items on the agenda which is in the notes.

C

um You probably should have a look at the notes in parallel to the meeting. um Actually five items three are on these slides sibo, packed um the discussion about array, tags and related tags that shape-shift uh sibo and um the progress on the alternative union tags. And then we have the agenda for iitf 114 and any other business which might include um the uh times we choose for the interim meetings for the fall.

C

So if you have anything else, this would be a good time to speak up otherwise I'll just move forward.

C

So we had a pretty lively discussion about sibo pact, and this means that we made some some um pretty pervasive changes. We didn't really change the the the underlying mechanism very much, but we repackaged it um in in a way that makes it simpler and uh probably more powerful. So we used to have prefix and suffix tables for for packing and we simplified this to a single argument table. So we have a share table and an argument table. Now we brought up the idea of a function tag.

C

The default function continues to be concatenation, so we have straight sharing and we have continuation um from the argument tables thread sharing from from the sharing tablets and coordination from the argument tables and we add a way to actually explicitly specify specifier function, and I have a couple of slides on what that what the first one of those should be, we had some some pretty bad terminology in the intermediate version, which talked about the type 0 and the type 1 reference. These have now been simplified to straight and inverted references.

C

They only differ in the question which becomes which part becomes the left-hand side and which part becomes the right-hand side, uh and this also simplified the way we find the function tag, because the function tab tag. If present always is, on the left hand side, so that's what what happened in in dash 06 and we said we wanted to have one function defined.

C

Originally, we had the idea to have a mid fix function, which is between prefix and suffix, but it actually turns out. We can generalize and simplify this to a join function, so this works exactly like python join um or like ruby join, except that ruby join is the other way around from python uh join.

C

uh So this is really funny for somebody who speaks both languages and the idea of a joint function is that you supply it with an array of items to be concatenated and you provide a joiner or intersperser that is put between every pair of items out of the array, so so broken uh or vertical bar dot join uh of four and bar becomes fu vertical bar bar bar is maybe not such a great meta variable when you are talking about vertical bars.

C

Sorry, okay, the the interesting observation here is this function is not commutative, um so that will come up in a couple of slides, um so we already had an example, and I have slightly updated this example now, where we have a target of a free, an array with three uris, and we want to put this together out of a common part, the pack.example and prefix and suffix, and I probably mistyped this sorry.

C

Wow, okay, so this is totally wrong um yeah, so you you need to to imagine that the target looks different from what I have on these slides. Sorry about that, um so the the idea is that the um actual ramp table uh takes https and food.html and puts this around. The pack.example is essentially a call to the join function where the array is https and full.html and the the joiner the intersperser is pack.example, and this way you can put together these three uris and sorry.

C

The the um text on on the top is the the wrong target from a previous example. Sorry, um and the same thing can can also be done the other way round- and this shows in the second column- and this shows some flexibility of being able to specify the function, tag on the using side and not in the argument table. So in the left hand side example, we had the 106 the the function tag on the joiner.

C

So when you use that- and you reference that, then you implicitly activate this function, tag and put things together together. Based on that, um on the right hand, side, the function tag is uh at the side where um the argument is being used, and that, of course, has the advantage that we can leave this out. So, for instance, where we put together the mail to uri, uh we we don't really need a joiner. We can use simpler. Concatenation and simple coordination is the default. So we don't need a function tag for that um yeah.

C

So this shows the the fact that we have references reference tags that offer both orders. The sixth is the the straight reference to argument: table entry, zero and two one. Six is this inverted reference to argument tag zero and you probably have noticed that there are two different function: tags here: 106 and 105, because by inverting things you actually also have to invert the sense of the function tag. So we actually need to define two function: tags for a non-communicative function that that actually makes sense in in this.

C

In these two um combinations, now we we could maybe arrange reference tags in such a way that they fit the example on the previous slide. But then this is an example where we actually uh need both directions of the reference tag with the same direction of the function tag.

C

So in essence, we have four different combinations and one bit for those. Four cases comes out of the reference tag and the other bit needs to come out of the function tag assuming that we have a non-communicative function. If we have a commutative function, then of course it does make a difference and we only need one function tag or if we have something that only ever happens in in one direction, we would also not need a second function.

C

Take so that's the somewhat bitter result of running through this example, we may need two tags uh to accommodate a particular function.

C

Okay, so that that's the the result of the discussion uh here- and I made some some very simple slides- you probably really have to read the the document to get at the finer points, um but the result is that we now have a relatively simple set of uh tools in our toolkit that we can combine in a pretty flexible way, and this is exactly how how this should uh look like.

C

So I think we are pretty much done with this. The only remaining question is how many of these other items that came up at the end of the last meeting. Do we want to address here. So one question was: do we have a way to address sequences and it probably makes sense to have an unwrapped, splicing uh kind of construction, but maybe that has to go into sequences and not into a package. I don't have a strong opinion on that.

C

The second question was: do we want to address any further function, tags and the candidate here was the curry, but that probably better goes into something in the context of the co-working group which needs this function take for for operating on uh concise resource identifiers. So it's not really something that sibo should be doing, and the third question was: do we have.

C

Something convenient we can do with the fact that we have.

C

Only a few type pairings in the reference tags that actually make sense so whole world is essentially unused here, but on the other hand, nobody has come up with something useful to do there. So maybe we could just leave it as it is so that that is uh by my status of sibo package, and the next step, of course, will be to update the implementations to uh what we have changed in the last version, and I hope you will be able to discuss the implementations at the 114 meeting.

C

A

Sounds like it's all spot on good.

C

Yeah again, it's too bad that christian is not here, because this was mainly reacting to his uh comments.

C

Okay, so let's move on and that's probably the part that kell is interested uh in.

C

We have a long running discussion in the zebra working group about how to actually define tag validity in terms of what can go into the tag content and we had several discussions about something called semantic tag validity, but this turned out to be pretty wishy-washy and uh for eight nine, four nine. We stuck with the structural tank validity that most people probably had implemented um in in their uh decoders and and validators. So a tag essentially looks at the shape what it finds in its tag, content and this.

C

If this doesn't look like what it expects, um then we have an invalid tag.

C

So an example of this is the the multi-dimensional array which is all about arrays, obviously, and the the data item that goes into the tag. Content of a multi-dimensional array is an array of two items, one of which is an array of dimensions and the other one is an array of the actual elements of the multi-dimensional array and, uh as you can see from this slightly shortened text from the rfc, this gets a bit complicated. The outer array is always a c bar major type.

C

Four array: the dimension array is always receiver major type 4 array, but the element array can be either such a major type, 4 array or a typed array or homogeneous array which are tags that are defined in that rfc.

C

So, essentially, we have um tags defined in this rfc that hold something hold some data that are meant to stand in uh for actual sibo arrays. They have the same function, uh but at the the site where, where this is used, we actually have to say that this needs to be allowed and that that's, of course bad, uh because it leads to an extensibility problem and that's exactly the problem that kell has at the moment.

C

He wants to extend this and now the question is: what do we do with the existing um multi-dimensional array tag, or do we need to define a new check that has exactly the same meaning just because we have one more tag that can stand in for a receiver array.

C

So really, uh this is a festering problem that that we haven't found a good way to attack, but with sibo pact. Of course, this becomes completely impossible.

C

This approach, because uh the the reference tags in sibo packed uh also go into random places into other tags, and so the the shape that the tag finds uh has an unexpected reference tag um possibly, and uh we need to to find a way to allow cyberpeg to do this, and when we allow sibo pack to do this, we might as well uh provide some license for other tags uh to do this as well.

C

So a zebra pack reference tag again would stand in for what it references and this this idea of a tag standing in for some shape. That is expected. That is maybe the the principle that we would be working on. So the idea is to make explicitly an equivalence principle. So this is not yet full the full concept of semantic tags, but it goes into that direction a bit.

C

um So what we have today is tags can define the shape of their tag content, so they they define down from the the tag, um but they cannot define up and the the new idea is that tags can define what shape uh their their users. Their environment should see when they look down into tag content.

C

That has this tag, so this is about two texts being nested, uh maybe with interspersing arrays and maps, and so on, and by saying that that a tag is equivalent to the array or the map or some other structure that that it actually stands for.

C

uh We can avoid having to change the surrounding tag, and so we can, for instance, have a data compression tag that can be used in all places where a byte string can be used, or we can have a new typed array tag, for instance, for uh some some other uh popular floating point format, like b float, 16 um that that can stand in for where the the existing set of typed, arrays or even standard zebra arrays uh can can stand in and what we have with the typed arrays is essentially we have this stand in concept already, but we have it in a very limited uh way.

C

We have kind of jailed it to to the particular um environment that we were looking at in in this roc and that's probably wrong um yeah. So um I think this is a good idea, but uh a good idea um is just that, uh so we need to rate this up, write this up and I'm wondering what what the best form is. We can that we can give to this.

C

So, for instance, we could simply use sibo package um as a document because we're working on the document uh to establish this equivalent equivalence principle and then other people who register tags like lz4, compression or v-float 16 floats or whatever can simply reference that we could also put it into those specific tag, definitions, but I think it's a bit weird to have one tag, definition essentially reach into the the internal mechanics of sibo and and change the way tag validity works.

C

um I was also thinking about whether this actually updates eight nine four nine, because eight frontline defines tag validity in a structural way, and I was also thinking about whether this can be opt-in, so that that's a number of questions we probably need to clarify again my my current uh uh favorite is just uh putting this into the pack document, because that's one we have in the pipeline and it's actually needed for pac. So we we should be doing this, but yeah I'm open to two other ideas: how to do this.

D

um Would it make sense to make her walk in on a tag? Focus? Is that what you mean by opt-in.

C

I have problems hearing you, oh can you say that.

B

C

I'm just um english is not my native language. um Okay, just say this slowly again,.

D

um The the opt-in um part, I had a question about, um does, would it be opt in on a per tag basis, so would a tag basically? Would it would it be in the definition of a tag or description of a tag that um that it's um that it would accept any, I don't know semantic uh convertible or I don't. What did you call the stand-in types, uh um or would this work up for every tag automatically.

C

Well, we have uh a hundred or so tags defined so saying that each of these tags needs to position themselves to this. um It's a non-starter. We can't get this going. I think um so. Opt-In was more on on the same level as people opt in to deterministic, encoding or to indefinite length uh strings.

C

So it's it's one. One other check mark you would make when you say. Oh, my, my my uh uh c bar decoder actually can do tank validity by equivalence.

D

Yeah, okay, so you would do it on the decoder encoder side or I guess, decoder side.

C

Yes and and of course the the other opt-in is that um to be to say that there is there even is a equivalence relationship. That's really opt in for the specific tag that establishes this. So if, if I do an it's a four compression tag, I would explicitly say this tag can occur in all places where by strength can occur, um and that's the opt in by the tag that that goes into the equivalence.

D

Yeah, my my question was whether the tag that consumes such tags- if they need to opt in too so that, for example, that we would only allow this on on things like typed, arrays or multi-dimensional arrays um yeah, because that's another way you could opt in.

C

Yeah, but that becomes an n by m problem and I'm I'm not sure how to avoid this becoming a quadratic problem.

D

Yeah, I agree that it's more useful, if you don't make every tag opt-in, so I'm leaning toward it makes more. I mean your initial suggestion that uh that it it's like it's opted on the basis of the decoder uh like, like you mentioned. um uh uh What is it called um the encoding, the the standard encoding.

C

Deterministic deterministic.

D

Yeah exactly uh deterministic encoding. That's it's often on that level. In a similar level, so yeah yeah, I think that's definitely easier to it's more, maybe more useful. It allows it allows each encoder to make the decision themselves and then each tag doesn't have to deal with it.

C

Yeah, we only have to to be careful that we don't fragment the the situation by by every decoder making a slightly different uh decision, so I think that we should uh um ask for a wholesale opt-in in those. I.

D

Mean because, but I was thinking I was thinking that like, if you take pact for an example, what what would it mean if you had, can you have recursive pact? If, because I mean if you, if you.

D

What would so is this something that people are thinking is a use case or.

C

Well, it's not a use case. It's just a mechanism that can be used in various use cases, and one use case is that we often have extremely complicated json data structures, and these need uh some way of of collapsing uh branches that that are copies of each other, that that's how this whole thing started, and then we noticed that the the carry mechanism that is often used uh in in json also can benefit from uh using the pack mechanism and so on, so that that's an example for, for a use case for packed.

C

Not true, I answered your question.

D

uh It wasn't, it was not really a question it was uh well. I mean I was asking, if that, if there are, if, if you guys already have use cases for like recursive applications of pact as an example right because you would have you could have packed generate some uh string, which then is used as an input to another pact right.

D

C

Yes, we definitely have that, so you have to be careful with the term recursive, because recursive actually means recursive, which these use cases are not there. They are arbitrarily nested and, yes, we have use cases for our literally arbitrarily nested application, suspect.

C

It cannot be recursive because there would be no way to end the recursion.

D

Recursion, in the sense that, as an as a decoder you always have to um you can never you can never um when you're parsing the data item for for a tag.

D

You always have to recursively um look at the next data item, and this could go many many levels deep until you can can decide if the outer tag is is correct.

D

So in that sense, it's it's recruit it's it's like every yeah, I'm not sure if that's a correct definition of uh use of recursion, but.

C

Yeah, that's why it's so so difficult to use the term recursion, because it really means something on very, very many different levels. But if you do a validity check, uh then of course you you have to resolve all those stand, uh relationships uh that govern this validity and that may be packed. That may be something like like exit four tags or um some some alternative floating point formats. All these go into validity considerations, so the the idea how to handle this in an implementation is that of an accessor function.

C

So if, if you have an accessor that allows you to to go into a c c or data structure and that accessor finds something that stands in for something else, it delivers that something else, and that indeed, is in a loop until it returns something that is genuine and and doesn't uh stand for itself.

D

So, okay, so and then the the second question main question I had was you mentioned: typed arrays uh at the b float 16 example, um and that so in in the example in the lz4 example, it's very clear-cut what's going on, because you would define that the lz-4 tag produces uh an equivalent to a byte string. Basically yeah, that's defined, that's defined in the um in the main uh sebor rfc8949, but in the b float 16 case I mean it's, it's you.

D

What are you producing you're producing a typed array, so you somehow need you to find a class of things that say that that is. That is that that meets the definition of typed array.

C

Yeah, that already is defined in rfc 8746.

D

Right but it doesn't include, b, float 16., so if you're trying, I'm saying it as their tag author, like if you're trying to add another type to the typed array class like there, is no defined class. In that sense I mean you could just say as if it were a typed array, but well.

C

It is a typed array once again.

C

So in this specific example of a b float 16, uh the the stand in relationship is that uh this looks exactly like a float32 array um after you have replaced uh every uh set of two bytes by those two bytes and two zero bytes. uh So that's a very simple stand in uh relationship.

D

I mean but but see the typed array example I mean there are there are in in the in the 8746 document. You have a a list of different type types that are supported, and then uh it describes those collectively as typed arrays. But if, if you after that, then define a new type, so b float 16 is not any of the original types, so you're you're you're, basically expanding the scope of of the list of types that are in typed array.

D

In that sense, so you have I'm just wondering if, if you, if you've been thought to how that would be written as a if I was if I was writing a a tag for b-flat 16. How would I express this so it would be correct.

C

Yeah, that's an interesting editorial exercise which I haven't done uh but which I also don't think is really complicated.

C

I mean, you would essentially say you're treated like the other type of race, um and that would be it.

D

Yeah, that's fine. I mean that would work for me if, if, if that's clear enough but.

C

I think it would.

D

Be a good exercise.

C

To to actually go through this and define those tags um in the next couple of weeks, or so so we know that we can pull this off.

D

Well, I guess my I might I guess what my uh my question is is is maybe it probably makes sense. So whatever document um gets written, you mentioned putting putting these definitions as part of the the packed uh rfc.

D

I'm not sure I I mean it's fine for me, but I I don't know if it makes more if it, if, if it's a big enough change, that it warrants its own rfc and then the pact would would just um depend on that rfc. I don't know if that makes more sense, but either either way.

D

um I'm I'm asking if, if wherever this is defined, it probably makes sense to somehow put that I don't know put this framework in in this art in the new rfc to to easily allow tag authors to do things like this, so that it's not so wishy-washy. I don't I mean yeah, you could just write yeah. It's a typed array.

D

But I don't know if that's good enough and then there's the other question about like discoverability, because how? How does that.

D

I mean if a decoder doesn't know about that. I guess it's. I guess that's fine. I mean if, if there's a new, I guess that they don't know about the tag. They can't do anything about that. But I wonder if also something needs to be said.

D

About about how error handling should work for decoders that opt in, because I guess any tag that a decoder doesn't know about could have been something that that um that stands in for the type they expect. Yes, so I don't know if something needs to be said about that too. In the rfc.

C

Probably I think that that's a good point that so um to me it seems we we want to put the actual equivalence principle into the sibo pact document and then write another document which might become an rfc or may just be a registration. We have this registration mechanism in ncbo that defines how to do lz4 and how to do b-float, 16 arrays, and if, when we write this, we find well. This is a little bit more than just the your garden variety tag registration.

C

uh Then we should look at whether this needs to actually needs to be a normative rfc.

C

Great because I appreciate that you you could make it to this meeting and such short notice. I think that was really having that use case was was really useful.

D

uh Yeah, and and from from my side uh I I think this is um a great um solution.

D

um It would solve our problems, at least so I I hope this can I so I don't know what the process is. um Is this a proposal is going to be written. Is this is this? Do you think this is more or less the direction that that will be pursued? Then.

C

Well, yeah, I think we have to do a working group last call for the cbo pick document or any other document that establishes this equivalence principle, so that that's one thing and the other thing is that the actual tag, registrations uh or tech definitions need to be written that define these. These compression and and typed array tags. We have one document called the notable tags document that already has a few such uh tag definitions.

C

We could put it in there or if you want to do this in a more independent way, you can just write it up put so somewhere on github and tell ayanna to register it so that there are several ways of doing um this and they they have different amounts of independence on one side and and support from uh people who are in the working group on the other side. So we can always decide how to do that.

D

Yeah I mean I I might- I might send a. I might register a tag that that meets this use case in the next few days. I guess I'll just write stand. I can already use the language stand-in in that. In that description, I guess I think that yes yeah, I think that's fine, that works for me. Thank you.

C

Great because the next item on the list is actually reporting that we went through the same kind of process on a different subject.

C

So, on the alternative, slash union, uh we had some discussions with the authors, and this text actually went into the notable text document uh in this case, because it's a pretty generic tag that can be used in in many situations and uh the the authors told me today that they plan to uh go through with the einer registration. This is vacation time, so they in europe. So they didn't do this um uh immediately when I asked them that whether they wanted to do this, but this is going forward.

C

So this is just a quick report, but it's also something that that is an example for how something like like these tags here can be handled.

C

Good, if we are done with this.

C

So I I take as an action to write the section about the standing principle or the equivalence principle in the sibo pact document and have that done by the 24th. When the.

C

Internet draft archive opens again, which is a little bit short before the zebra meeting at idf 114, but you can follow the repository as well. Of course,.

C

So barry you had some points about the itf-114 agenda.

C

Didn't put up a slide for that.

A

Yeah, so that this was um christian, put that uh that on and then told me that he couldn't be here to talk about it um is there. I guess the thing is is there's something we need to talk about? Okay, no, this one. Let's just do do your union.

A

Yeah do do your union tags one.

C

There was a interruption for me. I don't know if everybody had said that.

C

Can you say it again, I'm sorry.

A

My network seems to be a little funny today, um but yeah.

A

So just go on with uh with your with whatever's whatever's left in your slide deck and well. Okay,.

C

Okay, I only have this last slide for the the.

C

Four interim meetings, so there was a proposal from the core work group chairs to use the the dates you see on the right hand, side of the slide for call meetings uh which would leave the dates that are, on the left hand, side for the zebra working group. And the question is whether that that's a good cadence for interims between 114 and 115..

A

Now, unfortunately, ian is not on today and he's the one who usually has the the ongoing issue, but this this cadence that um that's proposed keeps our every two week pattern which should stay, which should still be good with ian. I think um I, I think we'll need to put this on the mailing list and make sure that it's okay, but does anybody on the call today see an issue with this schedule?.

A

Okay, so that's that's all we need to do with this today and I will I will post this to the mailing list after the call and confirm it.

A

um So, let's see what we have uh christian put something put on the proposed ietf114 agenda.

A

Does anybody have any discussion about the proposed 114 agenda? Anything you think should be added or any questions.

A

Now we're good we're good with those three items.

A

A

Okay, so hearing no discussion there, I think we're done with that anything else. We need to discuss today.

A

Are we likely carsten to have any document updates at the beginning of ietf week.

C

Yes, so, um as I said, I think we want to have a new version of pact that has this equivalence principle and any other comments that come in um on the tag side.

C

We might get some input on the time tag, because the sedate working group is making some progress and, of course, the whole cdl 2.0 thing needs to go forward and I have collected some stuff that just needs to be cast into internet drafts. So with some luck that might happen before the 24th.

A

Okay yeah, I guess that was the main question: will that will that get done by then um we don't meet until thursday right. So that does give us the whole week to peruse whatever gets posted early in the week right.

A

A

All right um anything else for today does anyone have anything to comment on any other business. Anything you want to chat about.

A

Hearing nothing, I thank everybody for coming today and we will see you in philadelphia or virtually there.

C

See you virtually then.

A

See you inside okay thanks everybody, bye.

C