# CALEXT Interim 2022-09-28T04:00:00Z   {#calext-interim-2022-09-28t040000z}

## Agenda   {#agenda}

*   JSCalendar Bis
*   AOB

## Notes   {#notes}

Very small group

Bron spoke to the notewell.

## Jscalendarbis   {#jscalendarbis}

Robert presenting slides

### Pause at slide 4:   {#pause-at-slide-4}

Neil:

*   Regarding the mapping -> think the first approach is what we were
    originally conceiving and have chartered things to be implementable.
*   Want everything from jscalendar to be backwards compatible, so you
    can convert FROM icalendar and upgrade to jscalendar
*   But we didn't originally intend that everything be backwards
    compatible to icalendar with new changes in jscalendar

Robert:

*   Thanks, yes understand your point. I'll go on and we'll look at it
    more later.

Finished at slide 6 with the scheduling topic.

Bron:

*   Can we make things backwards compat?

Neil:

*   Can make things match -> if it's mailto: it's IMIP, if other it's
    "other"

Robert:

*   Almost everything here is simple to map to icalendar, that's easy.
*   The issue is that for an arbitrary jscalendar participant that's not
    a representation of an icalendar model, we can map to any properties
    we define, but if other systems can't work with the data, then we
    always risk the fragmentation of scheduling.

Neil:

*   don't see how you get into that situation. The only way you'll move
    it between systems will have both icalendar AND jscalendar versions.
    Seems weird that they wouldn't support it.

Robert:

*   Understand that we can take a jscalendar event, map to icalendar
    using new properties - send it full blown including full information
    in icalendar to another system. If they support new properties, fine
    - otherwise they can operate with the data they know. At best, loop
    back other properties.
*   Server that understands jscalendar may need to merge information
    back.

Neil:

*   if you're creating a jscalendar from scratch, the scheduleid SHOULD
    be the mailto: IMIP for the most compatibility.

Robert:

*   would be happy for someone else to take the mapping.

Neil:

*   Will propose the mapping for jscalendar, icalendar and itip ->
    mapping from single calendar user address in icalendar maps 1:1 to
    scheduleid. If it's not mailto it's imip -> scheduleid becomes
    calendar user address - if extras, we come up with an icalendar
    extension.

Robert:

*   still missing how it works with iTip.

Neil:

*   Mapping is fairly easy
*   In terms of ITIP stuff, there's external vs internal. The way I
    thought this has to work is:
    *   I invite someone at an external system, that's going to have to
        include icalendar and jscalendar, there's no negotiation, so
        it'll be an email with both parts.
    *   The whole point of the model in jscalendar might include "here's
        how we can upgrade, we don't have to stick to IMIP".
    *   If they don't support the new stuff, they'll reply to the
        icalendar.

*   will write something up in an email and we'll work out what to do
    with it.

### slide 7   {#slide-7}

Have some properties which MUST have a schedule-id?

Neil: "participationStatus" might be useful regardless, not using the
scheduling system but storing the status for my own reference.

Robert: yep, OK - that makes sense.

Neil: agree with the rest. Don't know how important it is to prohibit,
but agree they're not much use without the schedule ID.

Robert: mostly because the LHS is stuff that's properties on an
attendee.

### slide 8   {#slide-8}

Deprecate iCalendar "sentBy"? Nobody seems to be using it. Fastmail
doesn't use it.  
jscalendar "sentFrom" top level is different.  
If we deprecate it in iCalendar then it doesnt' make sense to keep in
jscalendar.

Neil: makes sense to me to remove

Mike: never seen anybody set it, can't see any actual use for it.
Complicates things to a minor extent. Would be nice to rewrite the iTip
spec. It doesn't make it clear that you're better off sending as few
properties as possible.

Daniel: is it a problem to have this unused property?

Mike: just what happened to me - reading through the spec, and thinking
it's important, but it's not - just a complication that's unnecessary.
Might be worth saying somewhere that we deprecate it, no need to make a
big noise about it.

Daniel: do you expect a draft saying "this is deprecated" or do it with
jscalendar?

Mike: Was thinking about it in the context of the mapping - in
jscalendar just drop it. In icalendar just say it's deprecated.

Ken: I think if it's deprecated it needs to be in a revision to 5545,
but Mike is correct we should avoid using it in the mapping doc.

Robert: sounds like whatever happens to sentBy in icalendar, we should
drop it from jscalendar. Can map as we'd map any other unknown property.

### slide 10   {#slide-10}

Need to add replyToScheduleAgent to replyTo.

Neil: does icalendar have a way?

Robert: yes, set on organiser.

## ACTIONS:   {#actions}

*   Neil to write up the "repair scheduling" mapping for icalendar
*   Neil will update jmap calendars with new properties
*   Robert to add the replyTo schedule
*   Robert to guard the schedule properties
*   Robert to add deprecation of sentBy

Robert: if we go with replyTo -> make it not "other" because you can't
use it.

Was tempted to replace other with vendor extension property where vendor
is rfc5545 organiser, etc. Any server doing their own thing should map
to their own vendor space. This was just to map unknown icalendar URIs.

# AOB:   {#aob}

## Existing docs.   {#existing-docs}

Mike will update the drafts he is author on. Will make changes and
update to unexpire them.

*   tasks - some changes
*   vpoll - make just make minor changes and republish
*   subscription upgrade - was pretty close to completion Milestone says
    it should be submitted. Bron will do so.

Daniel: what about jscontact?

*   Robert and Mario are working on the RFC. Goal is to do last call at
    next IETF.

## ACTIONS:   {#actions-1}

*   Mike to refresh all drafts he's author on
*   Bron to submit subscription-upgrade to IESG once updated