documents: https://datatracker.ietf.org/wg/calext/documents/
material: https://datatracker.ietf.org/meeting/124/session/jmap
Mike was not available to speak to these.
ACTION: Bron to folow up with Mike on the status of ical-tasks and
subscription-upgrade.
Robert: Held back to discuss today, but proposes that we progress the
documents.
Robert: want to produce an rfc9555-bis document and as for adoption.
ACTION: Orie to progress jscontact-uid and jscontact-bis documents
ACTION: Robert to submit an rfc9555-bis document for adoption
Do a WGLC for icalendar-jscalendar-extensions.
Robert: would prefer to do after IETF126, for sure by July
Bron: do we need to WGLC again?
Andy: (ireesponsible AD) no, if you haven't changeed.
ACTION: Bron to issue a WGLC for icalendar-jscalendar-extensions
Nobody was interested in revising any of these.
Milestones were reviewed and updated.
NOTE: the jscontact-encryption work was added as a milestone to CALEXT
as well.
documents: https://datatracker.ietf.org/wg/jmap/documents/
material: https://datatracker.ietf.org/meeting/124/session/jmap
Neil: it was all the way through the editor queue, then we pulled it
back. Had quite a bit of feedback as Stalwart was implementing it.
Mainly pulled back for jscalendar-bis, heavily relied on jscalendar, so
wanted to not tie to an old version.
Neil will publish a new version today with changes from last few weeks.
ACTION: Neil will publish a new version of jmap-calendars, but will wait
along with other documents for implementation experience.
Neil: don't think there have been many substantial changes since last
IETF, just waiting on implementation experience.
Mauro: discussion about batching on the mailing list.
Neil, will update the document! It's just middle of the night here.
Using proposed JSCalendar grouping mechanism.
ACTION: Neil will update the emailpush document.
Hans Joerg: about metadata, questions.
Not sure how group store vs own store.
Bron: separate accountids
How do I know if I OWN the folder?
Neil: in particular, need to make sure this provides everything we need
to add JMAP Files as a remote file adaptor on Mac and Windows. They both
have APIs for integrating remote drives.
ACTION: Bron will update the filenode document with guidance about
shared accounts and ownership
Alexey: I meant to do something with smime-sender. Remind me in January!
ACTION: Alexey will do something with smime-sender document.
Hans-Joerg: decide to park some of them. Promised to do some work on
Tasks.
Good news, we're updating to recent versions of specs, so want to
progress spec work on tasks.
ACTION: Hans-Joerg will update tasks document.
PHB: this is a call for adoption of the draft.
ISSUE: vcards don't understand how crypto keys work. Need glue to say
"this key is for this application"
In the past, you had one key - now we want to separate different keys
for different applications.
Also proposing some crypto stuff in JOSE around this, that allows crypto
around it.
Looking for co-authors.
Bron: we're not MAILMAINT, but do you have anyone else working on this
who will come here?
PHB: not at present. This is a small increment to jscontact. Once you
publish it's hard to change it.
Robert: would be happy to give guidance on how best to fit this into the
JSContact model. But I'm not a crypto expert, so unsure how this group
can make sure that is the case.
PHB: two parts, one in this group, one in the other groups - PGP, etc ->
what do you need in the contact?
Robert: the other question that will come up if this document is adopted
by working group, how do we deal with our CALEXT charter?
PHB: if we get it right in JSON, we can work out how to backport it.
Hans-Joerg: data portability enthusiast. I understand that I could
update the email address in the signed document. I missed it on the
mailing list, seems maybe interesting for portability use-cases.
PHB: If you're sending emails around you could put this as an.
Andy: (no AD hat) - can't help you, but think this is extremely useful
work. Will make JSContact useful outside the email context.
PHB: ssh has useful tech to create certificates in SSH format. Want a
different key on each machine.
Jim: (no hat) - in terms of crypto expertise - this is just publishing
public keys and metadata.
PHB: will write proposal of how to do it, send it to relevant WG,
suggest how to do it.
Jim: don't need to be cryptographers
Ben Bucksch: interested in "can change email address". Would like to
hear more about how that works.
PHB: change from example.com to example.net, go to jscontact manager,
add new address, hit "publish" and the record is signed and pushed out
to the publication point specified in the contact. People who have a
contact manager which supports this extension will check the contact for
updates.
Ben: where do you publish this?
PHB: right now the draft says "http server". If we had millions of
people using this infrastructure. We don't need to build this here and
now.
Ben: might want to consider that spammers would use this.
PHB: you don't want to put too much information in your contact maybe.
Might want to have separate versions of the contact that you give to
others. Yes, there are privacy issues.
Micke: in open cloud mesh, we have a rudimentary contact information
that is exchanged, so having this URL to refresh a contact would be very
useful. Would also be useful to be able to roll the URL. Also looking at
OpenID connect User ID token to do the authentication. This sounds
interesting; something we've been thinking about using.
PHB: the fingerprint of your public key and the unique ID of the contact
uniquely specify an update. You can float the information out of band.
Hans-Joerg: in SML working group, a similar case where one could signal
"I have left the org, here's my new address". That might be a good
channel to convey a pointer to the changed jscontact.
VCard is just positive information. I can't state "this is my old
address". Might want to say "this is my previous key" as well?
PHB: for signature keys, yes - you might want to say "here's my old
key". There's a mechanism for preferences in jscontact already. Think
this is interesting but want to get experience first.
Also need to think about post-quantum PKI.
Also doing certificate revocation with bloom filters.
Bron: you probably don't want the URI with your provider!
PHB: you can have multiple URLs, yes.
ACTION: Bron to do a call for adoption on calsify list for
jscontact-encryption-extensions draft.
Neil:
Mauro: a separate patch could expand to nonsense.
Neil: yeah that's OK, you'd get
Robert: had same comments about hashes and property names. Working
group; we could reject people adding property names with a hash.
Neil: on metadata; have a few things. Bigger question is how it related
to /changes method. If you change the metadata on the object, do you
expect the object to have changes? Or just the metadata? Don't know how
that will fit with client implementations which are storing it with the
parent, or when you're gettin changes across parent types.
Mauro: Also with the 'private' type, do you see changes if only someone
else's private type data has changed. In Madrid we also discussed the
server settings.
Maybe the correct thing is have a different spec for server settings.
Regarding the changes, could also not have changes and when any metadata
changes you do a changes for the object and clients that don't
understand it will see a changes even though nothing changed.
Neil: issue is random stuff will be thrown in. Maybe that's good. All
sorts of things will be thrown in. Wind up with a load of incompatible
things.
Mauro: the server can restrict what's allowed.
Neil: I'll write on the list
Bron: shouldn't call it parentId.
Mauro: should also ask on list about separate draft for server settings.
Bron: will do separate call for adoption for each of the 3 documents.
ACTION: Bron to create calls for adoption for Mauro's 3 drafts
Milestones were reviewed and updated.