Minutes IETF113: calext
minutes-113-calext-00

# 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?