Internet Engineering Task Force Interim Meetings, 28 Sep 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF-CALEXT-20220928-0400

Description

CALEXT meeting session at IETF
2022/09/28 0400

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

A

A

A

All right, we have not much in the chat we have. People and O'neill is probably going to appear in a moment as well he's wandering around the place.

A

So I guess hello and welcome to this collect very, very small interim meeting.

A

Are we expecting anyone else.

B

A

Yeah I I haven't heard anything otherwise, so it may just be the five of us, um in which case as the chair I will say, I am quite sure that you're all very aware of the note. Well I, don't have slides on it, but please do note that we are under the note well at an ITF meeting and then let's go for it Robert. If you would like to speak to your slides, I can also unshare them and you can share them if you'd like to have control, I, think I think I can pass control.

A

In fact, there we go.

B

All right, hello, um okay, haven't ever but I now I see the controls for the slides, perfect, yeah, all right, um all right, so hello, everyone, um I'm I'm, going to do I suggest I, do a short presentation um which, given the people attending today um so I'm, going to take one step backwards um and um start the start, but might seem like an unnecessary high level but I think at the end we will see that it, um it might make sense to detangle the discussions we had over the last months so bear with me is what I'm trying to see here.

B

So why are we having this meeting um when we publish Chase calendar um in July 2021?

B

um We already had started working on the on the mapping draft the GS Canada I. Can the draft, but realistically um our main focus until we had published the JS calendar. Rfc was mapping from I calendar to JS calendar, and this was in retrospect, really just a trivial part.

B

um Whereas mapping from JS calendar to I calendar, we didn't really put much focus into it um until RFC 90, 89 84 shipped. That was due to several reasons we were. We were tied up with publishing. Js calendar, we were having other obligations at work too, and um also nobody really had any other implementation than the one we did in Cyrus and the one we did in Cyrus was always very experimental.

B

um So in retrospect we probably should have not shipped RFC 8984 before we shipped the jsk um before Chase calendar I. Can the ozone was published, but that's how it is now.

B

um So it was quite late about a year later only that Mike and I had identified issues with the scheduling properties, and this is now about half a year ago, and since then we are going um having discussions back and forth of of how to fix this, but really I, don't even with the partial result of last ITF. I I really don't have the feeling.

B

We have come to any any stable, um any stable setup with regards how to um how to do scheduling now and what should be changed if anything, but as I wrote on a mailing list, I, don't think that I mean we can't really proceed with GS Kell in the business. Until this is settled it's it's like. It doesn't make sense to me to work on GSK and the piece when we come to scheduling that's um kind of defeats.

B

The point of the whole exercise, so my goal of this meeting is to come to a decision with regards to scheduling, and if we cannot do that, then we should have a very clear picture on the questions that need to get answered so that we can come to a decision.

B

So the issue- that's really just a recap, is we figured out that the scheduling models in in the two formats, if they only are format or different models, we see uh differ in I calendar. Everyone knows we have. We have just been attending the participants, we're seeing the calendar address um and this is used for both identification and scheduling and there's only just one way to schedule and that's this single calendar address and in JS calendar we we start to separate that we have like a unique participant identity.

B

That's that's um independent of scheduling, um and this is not something we can currently represent in our calendar and we might not even be able to represent this in icann in the uh backwards competitor. In the temporary case.

B

And now something that we have that are always such a freedom was lurking underneath the discussion when we were discussing about specific scheduling properties in the last months, but never really addressed and I. Think we should do this in this meeting. If um who we actually need to care and I think there are two different opinions um or or a protests today, at the normal approach is the JS calendar can vary well.

B

Chase Canada support the existing icon in the data model, but it's it's free to extend it and we like to have expenses that are not necessarily representatively represent the brilliant eye calendar completely or probably not at all, and if I read the abstract in section one of the RFC, that's kind of hinted at and I think this was the working mode for a long time of drafting DJs Canon RFC, whereas the other approaches that we say this is really just the same data model for the the same calendaring model and you should be able to use either format um and have several Services speaking one or the other format to to interoperate, and this is currently the calex chart, I see.

B

Needless in the queue I just finished this slide, um this is basically the calyx Charter. It was recharged in my if I remember right when we published the JS calendar RFC.

B

um Js Canada extensions um must be must cover both formats in the robust mapping, including itip, and even this wording signals to me that at that time we thought we are, or we already have this robust mapping, but it turns out we did not so um really the JS calendar if he currently doesn't live up to the standards of the current Charter.

B

Okay I'm going to pause here and give me the mic.

C

uh Thanks Robert um yeah I just want to say on this I think you know that Earth approach is what we were initially conceiving and he's. What we were literally charted for I mean we kind of changed this data to try and say well, everything has to now be high calendar as well like one of the point was that you should definitely be able to. You know, represent everything in the JS calendar, but um you wouldn't necessarily need to keep maintaining. You know everything forever, because.

C

um And I know I, remember Rick, raising some eyebrows, that's uh my CTO here for other a few members that aren't FastMail on this call uh at the new Charter. That uh discussed me with him quite a few months back the idea that we would also be trying to put everything into our calendar too so I mean I. I think this is a really good thing to bring up on the slide and um yeah I I. Think at least originally our approach was. We do not have to make everything fully representable in both.

B

um Okay, thank you, Neil um brown or Neil I, don't know who of you, but there is um someone speaking in the background, so it's hard hard to understand. um um Okay, I'm going, but I understood you Neil, and um we will get back to this uh to these two approaches um later on. When we come to um what I think is the main message of of this life.

B

um So now, let's just have a short look at the two models for proposed scheduling models, um as you can see in the two right most most right: columns, um I labored them as the one is really trying to repair scheduling- and this is this- is what what CS calendar is aiming at um and the other one the other proposing is to like reuse scheduling. It's just it's just trying to use what's there, um and this is Mr summarizes, or this just goes into more detail. What I said before you can see.

B

We have multiple um scheduling methods um and we have a scheduling, ID um and um yeah I. Don't think I need to go much into detail because of the people in this course I think they all know this model more or less and the the the other one. The real scheduling is even simpler.

B

um That's really just what's there in I calendar mapped to JS calendar, um with the exception that we make room for later on adding additional scheduling methods. So it's um they're not completely mutually exclusive, but, um as you can see, they differ how they begin. Oh Daniel, hello,.

B

um Do you should I continue, Daniel or I wasn't sure if uh I thought just? Oh, you just turned your video on okay I understand now.

B

um Good um I will just continue with with the with the next slide. uh We came back to this slide came back to the slide.

B

If you just need to discuss the theaters and now when we I think what we really should do is look at the in at at how these approaches and and understandings relate to each other, and there I think if we, if we go the repair scheduling, so they say the JS calendar way um and we say that CS calendar can be, can have more than I can and then it's really straightforward for us to publish the rfcs I mean we can Define whatever we want basically, um but it means that um we can't map everything to our calendar um and and I think this makes sense if we bet on providers to adopt JS calendar.

B

Otherwise there is um it's more or less that features I mean to to adopt Chase calendar soon.

B

That's kind of missing in this slide here, whereas if we, if we keep with the repair scheduling approach, but we say um we do what the chart currently requires us to do, then, then that's going to take considerably effort and I'm not even sure if, if there will be any way to be backwards compatible for our cases, um but the the main idea behind this would be that um providers either adopt JS calendar or probably it's less work for them to implement the changes that we bring to our calendar with this repair scheduling model.

B

So it gives them two options on which we bet. Of course, providers can just not Implement anything, but let's say we bring enough with new stuff on the table that they see the value for them and the ReUse scheduling. There is really just um one one thing to this: consider because in the JS calendar there's more than I calendar, that's not applicable because we don't bring anything new in JS calendar to scheduling, um and that's of course it's easy to standardize um it's.

B

um It leaves additional that the repair scheduling, work to experiment, probably future standards um and it, but it it it. It bets on the chase. Kinder brings enough other stuff on the table that um people still are interested in implementing it yeah, and this I think this is really the. This is really our decision, Matrix that we should look at. We should not just look at the specific scheduling model, but also look at um the mode under which we are really developing this standard, because um this was I think missing in the last month.

B

This is the end of the slide for for this specific topic so um hopeful. Hopefully, we can have a discussion about that now.

A

A

Myself in the queue first, then, since no one else has jumped up, um it seems to me that reuse, scheduling now doesn't stop us doing repair scheduling later it doesn't stop us adding new things in a in a second revision. It's whether the first revision fixes everything straight away or whether we we go for the minimum possible now and add other things later. Does that map to your understanding, Robert.

B

um Yes, it does, if you go back once like I I can sorry yeah you're driving um the only difference is the um so. The participants schedule ID in the repair scheduling model, that's not defined in the video scheduling model. So that's not an issue because we can Define it later. Should that turn out to be the thing we want them.

B

The only difference is that um these last Parts delegated from and two they would refer in the repair scaling model to escape this schedule, ID this non-existent in the ReUse model, um but I think realistically we would always need to say the delegate it from and do they can either they refer to Uris of a participant that are either in descent to already scheduled ID. um So it's not um it's not that we are completely um blocking anything in the ReUse scheduling model.

B

Yes, the short answer is the real scheduling model is a is almost a subset of the repair scaling model, except for this last thing here, yeah um I think it.

A

C

Yeah, it complicates so get back to that slide. Please Robert I think that's a more useful one. It. It complicates um jmap calendars, a bit I think with the ReUse scheduling the the nice thing about the repair scheduling.

C

Is it separate that you is your separating um kind of the ID of the participant from how can I send messages to them uh because the ID, so at the moment, in jmat calendars, you've got to iterate through all of the things in like the Sims 2 and go do I recognize any of these Uris and then, um if so, this one's me, because one of the key things you have to do with a client is work out which participant is you I think it's a lot easier if there's just the schedule ID, because then you're just instead of having a nested Loop you're just is this schedule ID any of the IDS?

C

That I know is me um and so I think that's actually quite a nice property to have um for uh for perfect calendars um separately. That shouldn't be tied to saying You must have an imip kind of entry in the um send to uh you know you probably will for now, but that would be weird if one of those is like different to the others, and you have to know that it's not yeah.

C

So that's why I I one of the reasons I think that this this model is much better than the kind of reuse scheduling model.

A

Is there a way to get both of these with a a should, only do imip and have schedule ID match the imip as an initial? If you want to be backwards compatible, you have to do it. This way.

A

And anything that doesn't doesn't have that is no longer compatible with existing scheduling.

C

I mean I'm not quite sure what you're proposing there wrong the the like the one on the right kind of is also it's. It's specifically just an I tip URI rather than having I I'm it separately. No I think we we do want to register um a kind of perhaps a generic. It um thing for that which we can do in the registry.

C

You're ready, sending JS calendar, um but I would I use it specifically for non-male to addresses, because we already see systems that have this slow, like iCloud, has an internal URI for doing itip internally and then I'm at PRI for doing itip externally and they're both valid right.

C

It thinks the event and they can't represent them both on the I calendar event at the moment, because Icelander doesn't support that, and so they end up trying to rewrite them in various conditions when it's at the edges of their Network whatever, and sometimes that fails and you get the wrong one leaking out and you can't use it this method. You know the other is so much cleaner, whereas whether you can just put both of those in there and not have to worry about this rewriting nonsense.

A

Yeah as long as you're, never around tripping out of JS calendar into our calendar, for something which we'll certainly will need to be able to support for quite a while.

C

I mean sure, but I think um yeah ultimate. uh Ultimately, it's that goes back to that yeah, the question of kind of superset versus um trying to make them exactly equivalent.

D

C

Think we can mount this, um compare scheduling quite easily to our calendar. That's the other thing. I should say here like the schedule: ID Maps, exactly to whatever the calendar. The URI is for the participant at the moment, um and then that is also always um if it's a mail to an imip entry, otherwise or whatever. We call the other one item entry um and then mapping the other way we just have to. We just have to add some extra icon to properties for here extra Sentry methods.

C

um I, actually, don't think it would be too hard to map that repair scheduling one to Icon, one to one um I think it's essentially a good compromise from where we were before to something that Maps quite well.

B

So let me say this: um it's always it's almost everything here is simply to map to I calendar. We can always come up with new parameters and properties that never was the issue. The issue is um that for an arbitrary JS calendar participant with um so that's not actually a representation of an already of an eye calendar of the I calendar model.

B

We can map this to any properties we Define, but basically, if, if other systems can't can work with this data um because it's not backwards compatible, then then we always risk a fragmentation of scheduling so but.

D

I think it's not the issue.

B

Processing is the issue.

C

So but Robert I don't quite see how you get into that situation, because you're, like the only way you're going to move it between these systems, is via a message. That's probably like gonna have to have an icon under version and a JS calendar version for quite some time, because you don't know what your system is going to support, and so this would be that they support the JS calendar version to take that.

C

But then don't support enough to actually understand it when they map it back to Iceland or something that just seems weird to me.

B

um Well, I'm I understand this differently. um I understand this, that we can take a GS calendar um event, mapped it to.

A

I calendar using.

B

New properties um send it in a way that the send it full blown, including the complete information in I calendar to another system. If they support the new property is fine. If they do not support the new properties, they can still operate with the data. They know like we attendee address and stuff, but you can still at the best loopback the other properties to us.

B

So we um only only if the client, if, if they were, for whatever reason, throw away some of these properties, um the server that understands GSK and they might need to merge uh the information it has backup.

B

um But um that's my understanding how this may I mean it may work.

C

I think it's just a matter of saying you know if you're creating yes, ajs calendar from scratch, your schedule ID.

C

If there is an iMac mail to URI available for this participant, you should use that as your schedule ID um for that for the for the most compatibility, that's kind of it.

B

Yeah, but this this shoot is exactly the breaking point. For me, um it doesn't help. I mean I'm now, 99 of all the stuff here is is is not really the issue, but um it's still an Inc it. It's still an incompatible model at the very end and and when we, when we give when we standardize how people should map it um and- and we see there is a gap that can't be mapped.

B

We get back to the question of is: is this a superset or if this will argue, I'll be talking about Network models, and this is.

C

We agreed that we could map all of this.

B

um Well, when I say, map I mean map in a way that both um of course persists and allows to transfer the data, but also defines how systems should operate with it.

A

B

A

Think Neil's correct here that we don't need to. We don't need to both make it Backward Compatible with our calendar, by extending our calendar and Backward Compatible with existing implementations that don't know anything about the new scheduling, because otherwise we could never move at all.

A

So if we have a if we Define a mapping to our calendar, then we will have matched our Charter.

B

Okay, so that basically says we reach outer and um NCG okay and there's a superset right so.

A

No, no, we we have. The charter doesn't require that we never change scheduling. um We just say that we we have a mapping to our calendar for the extended properties and we we choose, which one gets mapped to the existing for most compatibility.

B

Well, um I've tried to write this multiple times now the mapping um I'll be happy for someone else to take it because I don't think I can um so, but if, if it works out great um but I I don't see it to be very honest.

A

Nil, do you want to have a go at at proposing the complete map.

C

Yeah I can propose how that should happen. I think that makes sense I, don't.

B

Okay, so then we cover GS Canada, I calendar and I tip the the whole.

C

So well, it's it's mapping from the so I mean essential problem. Is you've, got a single calendar user address um in I calendar that would map one-to-one to the schedule ID um as proposed here, and also, if it's a mail to it's an imip. If it's not a mail to it's, whatever we Define itip or new thing entry in the reply to a center. That's the easy way. Other way around is kind of Simply.

C

Reversing that schedule ID becomes the calendar user address and if there are any extra properties of applied to tend to, we come up with a way of representing those in I calendar, so that if we need to round trip stuff, we can store the extra stuff. That's an extension to Icon, because icon that doesn't support multiple properties. At the moment, if there's only one property in that then- and it's the same as schedule ID, then job done anyway.

C

It all just Maps you can't use address that is it as far as I can see, am I missing something there.

B

um I'm missing still the I mean I'm missing, still not the mapping, but the way the instructions how this should all be done with itip, um so I think um I. Think it's really better. If, if you summarize the complete um process, including requests replies and everything, um because at the very end we need this, other I mean this needs to go into this.

C

Well. Okay, so that's so that's there's two separate things: there's mapping this between eye calendar and JS counter which what we're talking about I, think that is what I just described and that's fairly well I. Think it's straightforward, then the in terms of eye tip stuff, there's um kind of is this external versus internal problem and the way I've always thought this is going to have to work, because the only way I can see it working is I.

C

Invite someone at external system to an event that initial invitation is going to have to include an icon and a part and a JS calendar part, because I have no idea what the assistant's for there's no negotiation going on here. The only thing you can use is email because there's no other defined standard for this. So that's going to go to the Finish invitation, but the whole point of this model in JS calendar is the JS calendar version can then include here are some other ways.

C

We can upgrade this mechanism now we've found each other and found our you know different calendar systems, and we don't have to keep going back and forth with imip with um I calendar going forwards like that. But but that's we're going to require. You know, support on the other side as well, and so once they're both implementing new stuff. We probably don't have to worry too much about necessarily doing this in eye calendar. That was kind.

D

C

And if they don't support new stuff, that's fine they'll, just ignore the JS calendar entirely apply to the eye calendar and that will still work.

C

Maybe I should write that up more if that was hard to understand, like speaking, but.

D

Like in my mind, that.

C

Will Works nicely gives us a nice upgrade path and is pretty straightforward. Yeah.

B

I I I think you should just write this. You write in the in the standard raft because otherwise again we just have this translation back and forth between an email and um anti-draft. Well,.

C

I just think it's um I mean so so I do think this is not doesn't necessarily belong in this draft, though this draft, as in this, the one, the artist you're writing, is just how do I convert between an eye calendar and JS calendar that.

B

C

Itip is not I calendar yeah.

B

But I mean we can just create a new draft and put the info in there or I mean I'm. Just saying, write it like.

C

B

Did in a draft, where are you.

C

Writing: okay, yeah yeah yeah.

C

Well, I'll write something up as an email. We can work out what to do with it um and I guess.

C

A

Cool shall we move on to the other, to the rest of the slides.

B

I mean the rest of the slides is not is not um about this topic, it's also about scheduling, um but these were the slides um so for this discussion.

A

Sounds like we have reached a point where Neil will write up a proposal for how to make repair scheduling backwards compatible. Is that that what everyone else got from this.

B

So that's my understanding. Yes,.

A

Cool all right.

B

Good, um oh I have to click here so I just have, since we still have time so um I'm wondering if we should um guard a couple of participant properties that really only make sense uh for scheduling schedule, labor participants.

B

um So on the left side, the left bullets would be the ones where I think setting these without having a schedule ID or a send. To really doesn't make much sense to me.

B

um The right ones that you see is stuff that you can set on any participant um is that.

C

Participation status- you could have anyway, like as in I'm, organizing this and I'm just using this to keep track of who's coming I'm, not actually sending it using this calendar event to send them the email so I'm, not using the scheduling side of you know the calendaring system, but I am storing what I expect their participation status in this event. For my reference.

B

Yeah, okay, yep.

C

That's probably the main one. The rest, though, is I kind of agree with I. Don't know how important it is to like forbid it, but I do agree that yeah.

B

This is really again a bit driven by the fact when, when I do, when we Define the mapping to an attendee in I calendar, um the left hand side is the stuff you you see that are really tacked on as parameters on an attendee property um so for stuff, like participation status.

B

When we decide that should be um independent of a scheduled ID, then we would need to um come up with ways to put that actually into a participant component, which is obviously doable, um but I I just brought it up here, but yeah um all right. So the next decision, um I remember Mike, saying repeatedly. We should maybe duplicate eye calendar sent by um the parameter, because no one seems to be using it. I looked in our systems and we are not using it.

B

um The new sent from property, that's in a JS calendar option on the top level is, is not the same thing as the send by parameter um um currently in Gs calendar. We do. uh We do have this property, um but I mean if, if we say we deprecated an icon, that's there's. No, it doesn't make sense to uh keep it in CSK. Obviously,.

B

B

um Mike, um since you brought this up.

D

um No, can you hear me yeah yeah. It was just as a result of going through all this stuff and and also doing some experimenting I've, never seen anybody sell it and I couldn't think of any actual use for it.

D

um So it just sort of complicates things to a minor extent um and I thought if we were.

D

It would be nice to rewrite the itip spec, because it's it's over complicated, it's really difficult to follow. It's got all those huge tables which are irrelevant and it doesn't really make it clear that you that you're, better off sending um you know as few properties as possible. There are lots of good reasons for rewriting it and it just just sort of fit in with that.

D

B

Okay, so do we need to problem.

D

To have this unused parameter or.

D

Well, it's Paul. It's probably the the people probably go through the same process that I went through I'm sort of reading through the spec and I'm thinking that it is here. So it must have some importance. It took me quite a while to figure out that it that it probably doesn't- and it's not used by anybody and in places where you think it might get used. It doesn't get used. So um it's just a complication, that's unnecessary!

D

D

It might be worth saying somewhere that we just deprecated it done. You know giving noise about it, but it was uh um making it clear that it's not being used. But do you expect a draft saying yeah? This is dispricated point or um do you expect that to be done.

A

Well, we do that with a GS calendar.

D

um I guess it's I guess I was thinking about it to some extent in the context of doing mappings between one and the other. There's no point in mapping something that nobody's using. So in just kind of we just dropped and then I can- or we can just say somewhere it's it's deprecated because as far as you know, nobody uses it and um it wasn't a big deal. But but.

B

D

B

Sorry Ken go ahead.

D

Yeah I was going to say: I I think that if, if it does get deprecated, it needs to be in a revision to 5545, but I. Think a mic is correct. That we shouldn't do anything in JS calendar that requires us to map it to sent by. We should we should avoid using it in the mapping, as I think was what Mike's saying, because we intentificated in a revision to 5545.

A

Okay, right yeah.

B

So this this sounds to me like um whatever happens with descent by parameter and I calendar, uh we we should drop it from TS calendar. We can still map it as we would met any other um unknown icon the property, so we can preserve it in the JS calendar representation. If we want to um I think that's the best approach, given that descent by parameters uh in our calendar also not clearly defined, so we wouldn't even be able to come up with a clear definition: JS calendar without risking incompatibilities with the existing using our calendar.

B

Okay, perfect, um oh yeah- and this is just something uh I came to realize. um I- think we also need to add a schedule agent schedule for send properties for the reply to a separate properties.

B

Currently, you can just set the the scheduled agent scheduled force and properties on a participant so really on the on the way sending something.

A

B

To the reply to, but you would also want to do that for the reply tools yeah, this was just an Omission in my understanding.

C

Because I can't have a way to represent that at the moment.

B

Yes, you can set it on the organizer.

C

C

B

Yes, that's the real last slide.

B

Okay, that's that's all I had.

D

Thank you, Robin.

A

Okay, thanks for getting up so early.

A

So um I guess at this point: do we want to look at anything else? Do we want to just wait till ihf115 the actions that I'm aware of from here um uh that for the scheduling stuff Neil, to write up the scheduling and for the other stuff Robert will add the reply to scheduling stuff and we'll remove the scent by mapping and possibly just put a note saying that aware of this is going to be treated like unknown.

B

Yeah and I will: oh sorry. Okay, yes and I will also um uh guard these scheduling properties um that are dependent on having a scheduling idea sent to okay.

C

um I'll update cannabis, I'll update the jmap calendar spec with these two new properties as well. They'll probably need to be referenced in there for a bike, don't send a reply if this is blah blah blah.

B

um And so the goal is that we publish a new RFC draft for for next ITF, um so Neil I guess you will add the scheduled ID um through the JS calendar. Biz draft um on GitHub, then sure, okay um and I think that's the only.

B

Let me check and I think that actually the only thing that needs to be done in the jsk and Abyss for.

C

Oh and I tip or whatever.

C

Scheduling method and then you can use in the center if it's not not a mail to yeah. So.

B

I, yes, um so I'm I think that the other, um if we, if, if we now go with the repair scheduling model, then I think the other shouldn't other method shouldn't be defined because it's, um um it seems strange to me to to have like a catch or.

C

The point of it is just like it's a URI, but there's nothing useful. You can do about it, because it's some internal thing that only the persistent generated knew about it kind of thing. So, if you don't recognize it, that's.

D

C

What you can do um so.

A

Yeah I mean in that, like any vendor extension, you just anything else, the vendor extension. You can name it any unknown property. That's it's an.

C

Event well, I mean this is a bit like those iCloud internal Uris. You know it's what you want to put them under, you can put them under other. We can put something called itec or whatever like it's just saying it doesn't matter. If it leaks out, there's nothing you can do with it.

B

Yeah I was I, was initially tempted even to put in these slides, but I didn't because I didn't want to um blow up the discussion of this specific thing. I was tempted to replace other um with a vendor extension property uh where the vendor is ITF, RFC 5545 um um and then it's like RFC at 5545 um organizer for the reply tool and RFC 5445 is 10d for the um for descent 2, because that's really what it is. It's just it's just the value of this property mapped into JS Canada without any further meaning.

B

And and someone creating a new Js calendar object should like never put stuff like other in here. um If it's, let's say iCloud, they should put this stuff in their iCloud vendor extension, so the other is really just my understanding.

B

um Just this thing we introduced to map icad and the unknown icon in the Uris to JS calendar.

A

Yes, I agree with that that it makes sense to to leave this as being a vendor space. If you're going to do a vendor thing.

A

And everything else should map to one of one of the named things.

A

All right, um if we're done with this, maybe we should have a quick glance at the state of the data tracker.

A

A

And if I unslide, you I, think I can just do that yep and then share screen.

D

A

A

We have eye calendar extensions, just kind of I calendar.js calendar, this JS contact, which will be talking about and JS contact extensions at the next meeting. We also have quite a lot of expired drafts here, um scheduling controls we're going to let die. That was that was my thing and it turns out there's nothing really worth standardizing there, but we have tasks. We have series we have subscriptions, we have upgrade. We have V poll and I'm sure.

A

At least one of these I was supposed to have finished a working group last call and submitted, and that hasn't happened and now they're expired.

A

um So I I will email the individual authors and ask them to do something about that um to an updated version of the draft. Do we want to talk about any of them now, or should we just update the drafts and go ahead.

D

I can update the uh the drafts. I'm I mean there's tasks, there were some. uh There was some discussion about that. uh I I can make some changes and then update it to unexpire it.

D

um We were talking about v-pole this morning. Well, we can um I can have a quick, go look through it and then maybe just make some minor change and unexpire that again as well, we publish that.

A

Great thanks that will make it easier, too, plan them for the next meeting.

B

D

I recall is a task, and series should be very short.

D

um No they're, quite big subscription upgrade I think was the one that was pretty much uh um I, think pretty close to completion hmm and that's a fairly small spec when I up by on the expire. That thing I mean that's I think is the one that that's getting custom last call.

A

Yeah I'm pretty sure it has had a last call. You can see it's got the date on it that it's supposed to have been dealt with by now. Okay,.

D

A

Is 2022 time on it? Oh yeah, yeah, all right, Thanks that'll be good and then I'll I'll. Do the um I'll double check the the comments on it from the working group last call that happened via email, but I suspect I'll just submit that one straight through.

C

A

And probably already asked you whether you're aware of any IPR on it, but I might as well. Ask you in person now. Are you aware of any IPR in it.

D

No I'm not aware of any IPL correct.

A

Then I can answer that truthfully in the the write-up yeah, it's just USB author, so that would be easy.

D

All right, great cool.

A

A

A

Quick lapse and Milestones says yep, so it was just that one was subscription, upgrade was supposed to be submitted and tasks is supposed to be submitted in November. So hopefully we can get that done and out soon as well.

A

Excellent, any other business.

A

D

What about the um the GS contact and all those uh vCard stuff.

B

um I'm I'm working on Mario and I are working on the RFC, um and um this should. Our goal is still to be able to do not score uh at the next Ito.

A

A

A

That's everything I have thank you. Everybody I I think it's been quite productive, really yeah thanks for making time at this weird hour,.

A