# CALEXT Tuesday, March 22, 2022 10:00-12:00 Tuesday Morning session I --- https://notes.ietf.org/notes-ietf-113-calext https://datatracker.ietf.org/meeting/113/session/calext Intro and Note Well: 5 min New Charter discussion: 5 min Drafts with IESG: 5 min - draft-ietf-calext-ical-relations - 5 min Newly Adopted work from JMAP: 20 min - draft-ietf-calext-jscontact - 10 min - draft-ietf-calext-jscontact-vcard - 10 min Drafts in progress: 80 min - draft-ietf-calext-jscalendar-icalendar - 20 min - draft-ietf-calext-ical-tasks - 20 min - draft-ietf-calext-icalendar-series - 10 min - draft-ietf-calext-serverside-subscription - 10 min - draft-ietf-calext-subscription-upgrade - 10 min - draft-ietf-calext-vpoll - 10 min Milestones: 5 min # NOTES ## ical relations * Ken: suggest that jscalendar-icalendar mapping doc be the place that jscalendar info is put, don't hold up this. Strong agreement. * Francesca: ballot is done, IESG changes tomorrow, approve? yes says everyone. * Robert: there's link relations in both documents, so will definitely want to align them. * Daniel: Mike - will you be able to do it this week? Mike: Yes. Goal -> this draft will be done this week. ## subscription upgrade Think it's pretty much ready. Also uses link relations. Needs updating. Mike will push a new copy, then WGLC ACTION: Mike to upload a new subscription-upgrade draft, then Bron will WGLC. ## jscontact ### Gender and Pronouns Gramatical gender field and free text pronouns field. The free text pronouns field matches Google's people API. Next step is interop testing - Mario has an implementation. Robert is working on an implementation at Fastmail. Audriga also have one. Target for WGLC before or at next IETF. ### context * other values than work/private? * Alexey: what are the other cases? * Robert: should we expect people to register a new item at IANA, or just allow people to do freetext? * Alexey: would like to know what people are using other for. We can add an IANA registry, but if it's unsure why. * Joris: saw in several systems that they're currently using other. More generic question might be how to map to JSContact. So long as it can round trip, it doesn't need to be an official value. Should be mentioned in the conversion spec. * Robert: do applications that allow other also allow not setting a context? * Context is optional in jscontact, so that would map to other in other formats. * Would like to know if there are other contexts that people use! * Joris: makes sense * Barry: what is the substantive difference between an enum and an arbitrary string? Robert: it's a string, just register. * Barry: suggest "register with IANA with specification required". * Hans-Jorg: historically, exchange introduced the 'other' - just three values. Google allowed more than three fields, so had contexts. * Lots of applications based on the Exchange pattern. So maybe consider as a standard field as well. * Might make life easier for those adopting JMAP. * IANA registry: Google allows free-form contact properties, so IANA registry would be over-engineered. * Bron: sounds like round-trip might be an issue. * Robert: every type has contexts. There's also a free-text label field. In earlier drafts, "other" meant you can use the label. Specific value of "other" is the same as not defining a label * Hans Jorg: needs to be really clear what to do for other, but this seems OK. * Ken: plus one to other == lack of context. ### label currently label has special values - should make it always free-text and do a general scheme with either subtype, or define more types. same issue exists in jscalendar, so we can come up with the same scheme for both. ### discussion? No comments. Next important step is interop testing. Might be able to interop test by next CalConnect. Might do an interim at CalConnect as well. ACTION: Robert to continue to work on jscontact draft. ## tasks Added VSTATUS property -> mostly going to be simplified. Add new REASON property which is free-text. JSCalendar mapping, which way? * Ken: a lot of these parameters were mirroring properties as a per-attendee thing. * Mike: trying to get rid of Group param. * Ken: in favour of moving these into properties within participants themselves. * Ken: gut is to put the mapping in this draft and pull it from jscalendar-iscalendar. So we have an example of how future specs have to include a mapping. Relations is further along, this one isn't so far. * Robert: not sure what this would include for participant - everything, or just parts that are relevant. Will run in parallel with jscalendar mapping. Can work out what makes more sense. * Robert: general mapping of participant to jscalendar should be in jscalendar/icalendar draft. Extension should go in other docs. * Daniel: jscalendar-icalendar adds complexity. A lot of the reference should be from ical-js. Will have some stuff in the tasks document. * Bron: maybe it makes sense for this document to not mention jscalendar and the jscalendar-icalendar document to be the baseline alignment document. Next: Mike will make the outlined changes (drop group, create a REASON property). Shouldn't take very long. Will publish that draft (after the first two) * Daniel: would be great to have a JS example in this document, something tangible for a new person. ## jscalendar-icalendar Work was slow due to Robert's time. Now top priority to do. Errata for 8984. Cyrus has stable X-property version, plus standard mapping which is experimental -> will put into libical if accepted. Mapping for unknown properties: will look at today. ### Errata Francesca: Both verified now. ### GEO Property In JSCalendar it's a URI. Much richer information. Propose that we extend the value types allowed in icalendar. Alternative would be ALTREP, with maybe two conflicting values. Barry: Do a URI. Hans-Jorg: Propose retrospectively updating the icalendar spec. Isn't it possible to derive the value for the legacy property? Robert: yes, can do but you can't map the other way. So this allows preserving in icalendar. Barry: the problem with adding another param/field that lets you specify the richer information, but better to break backwards compat. Robert: geo property is rarely used. Alexey: also in favour of URIs. Also in the spirit of original format for how you extend all URIs. Saying it has to be geo URI is fine, but maybe not restrict from adding other URI types. Robert: In JSCalendar spec, we require a geo URI, so if we allow generic we'd have to extend jscalendar too. Barry: think GEO. Hans-Jorg: why improve if nobody much is using it? Robert: Apple have an X property with a structured location, that will be a geouri. Bron: do we change the mapping document to be a standards track document, since this is updating icalendar? Barry: yes. Barry: back on geo: if this was a standards doc, would be happy to use this. E.g. put an uncertainty on the GEO for home address. ### JMAP-ID property JMAP Id is more restricting than `UID`. Often non-JMAP-Id strings in practice. Need a way to keep the JMAP Id, which is only scoped within a the single object. No comments on this. ### CONTENT-ID Should this go on LINK as well? Mike, not sure. Bron: might want to add a CONTENT-DIGEST to this as well, matching the `Content-Digest` header that we're using in MIME. ### LINK-RELATION Long debate between Robert and Mike! Value can be URI or "SOURCE". Registers a new value. Robert: only value not covered in JSCalendar is a generic URI. Think we should have one parameter, not two. Neil: for links that are attachments, the spec says that's only if rel=enclosure. JMAP Calendar will talk about managed attachments, but jscalendar can't. Mike: sounds OK then. Robert: if there was an issue, it's solved now. ### RELATED-TO Also add temporal relations in related-to. Would map cleanly to jscalendar. Alternative is define any temporal relation between start and end. Issue if we handle anything between start and end, should we introduce more right now or just set start/end. Mike: inclined to add new property to vlocation rather than extend related-to. Think it's simpler rather than complicating related to. Robert: works for me, and we'll restrict to the jscalendar values. ### VLOCATION and PARTICIPANT have a UID might need to introduct the UID property on the objects in JSCALENDAR. These would be optional. If mapping to icalendar, would generate one that's used for both. Neil: is this supposed to be an ID that's consistent across multiple events? Robert: it's supposed to be a globally unique id. Neil: how is this different from the ID in the locations object? Robert: in jscalendar, the id in the map of all locations within the vevent only needs to be unique within that locations property - while a UID in icalendar is meant to be globally unique. Robert: would expect the UID for a location property for the same location to be the same. Neil: could map to the ID in jscalendar * Robert: might contain invalid characters for JMAP ID * Neil: could do reliable mapping? * Bron: might be too long -> could digest but not two way. Robert: if we keep them separate, lease friction. Ken: what do we do with a VALARM with a UID property. Robert: for VALARM -> the alert in JSCalendar is not as sophisticated as VALARM. Don't think we preserve the UID. * Ken: to round-trip this, might have snoozed valarms that refer by UID. * Robert: don't know right now. * Ken: should use same mechanism across. * Mike: Cyrus wished we'd always put UIDs inside components. Good way to identiy things. Robert: the more we introduce ICALENDAR components with mapping to JSCALENDAR, should we make UID be explicit for each? ### unknown properties There's iana-prop allowed basically everywhere Mike: inclined to allow properties that you don't recognise in any object. Alexey: looks like the original jscalendar restriction is not useful. So you need a way to allow conversions. Whether a magic vendor prefix, or new extension. If you recognise the property, just convert, otherwise need a way. Robert: there will always be stuff we don't know anything about. If we know, we should use the defined mapping. Ken: was going to suggest a JSON representation of a generic property/component. Bron: just put everything we don't recognise in a jcal, that exists and is a 1:1 mapping. If we have a registry, there will be different mappings. Implementations that currently do a snapshot of jscalendar RFCs would reject jsevents that use properties from later RFCs. Alexey: if you need to change from rejecting to accepting, do it as early as possible! Robert: won't be able to get an agreement within this session. Up to Robert/Mike to solve this. ### Next steps Bron: keen to have a set of test cases that all the implementations use. Robert: should we have two docs? Ken: since we're going to change mapping documents, should we refresh jscalendar and send as a group? Mike: suggested splitting the GEO out into a separate RFC. Using a URI is useful in the icalendar world. Ken: if we're going to refresh jscalendar, volunteer to be editor. Ken will also do the GEO bit. Robert: one more RFC candidate -> allow subsecond precision in icalendar time values. Agreed on having it in a separate RFC. Mike: did create a draft fractional thing. There's a demand, but it's no something that's generally needed. For process control, etc. Inclined to do as a separate RFC. Touches on so many things. Robert: generally agree, but if we don't have it then conversion to icalendar is probably lossy. Mike: yes but it'll break things. Updated spec to say round down to nearest second. JSCalendar might be missing subseconds in the RRULE. Bron: 4 documents (now 5... with tasks) * subseconds in icalendar * geo and etc * jscalendar refresh * jscalendar-icalendar mapping * issue tasks without the jscalendar bit Mike: We should have an initial section in the mapping document "if you're doing iMIP, the mapping can be a lot simpler" - don't have to represent everything. For replies, you only need to pay attention to the partstat. Robert: would prefer a separate RFC - didn't cover the scheduling part in terms of the protocols involved at all. Would rather just define the format mapping without protocol specific bits. ## NEXT STEPS -> keep working on. ## The other three * serverside subscription, vpoll, series * Nothing this time, will deal with later. * Ken: example in serverside subscription needs changes * Questions about VPOLL too - send initial and final result as REQUEST, but there's a separate method for changes. Why not use REQUEST?