EXTRA at IETF117, San Francisco

Thursday 2023-07-27 17:00 PDT UTC-7:00

Note-taker: Jim Fenton

##Intro and Note Well 5 min

Congrats authors for RFC9122 and RFC9394!

##RFC 9051 Errata - 5 min (Jiankang)

Several erratas:

Errata ID:6826
Barry: suggest hold for document update
Alexey: We use ‘deprecated’ in two different senses

Errata ID:7343
Alexey: That was the intent, but document doesn’t quite say that.
Barry: Space was necessary but text was not. Not sure if intent was to also make space optional
Alexey: It’s in the spirit to make space optional.
Ken: This is subtle change, sp leave the space
Pete: shouldn’t be verified because resp-text is optional. Only need to determine if space is optional, but that’s a different erratum.
Consensus: Hold for update to consider making space optional.
Daniel Eggert from Apple: There are servers that will not send a space.

Errata ID:7246
Pete: Says it shouldn’t have repeated the response from the request
Alexey: Thinks this is correct, but take it to the mailing list.

Errata ID:7323
Alexey: Example doesn’t match the grammar
Barry: UTF-8 is always supported, though
Accepted.

Errata ID:7518
Alexey: Intent was not to mix numbers and identifiers. Was well discussed on mailing list, follow what was decided there.

Errata Overall

Alexey suggests publishing a -bis draft
Ken: Need to fix the ABNF

##In Last Call

imap-jmapaccess - 5 min

Finished Last Call; no big comments. Very few implementations.

##Existing drafts

1)imap-inprogress - 5 min (Marco Bertini)

Comments from 116 addressed in new draft.
Need to be able to flag feature availability of feature without requesting it.
Alexey: Need closure. Don’t feel strongly about removing capability name or keeping it. Would clients change timeouts? Keeping it is fine.
Next action: New version of draft

2)imap-messagelimit - 5 min (Alexey Melnikov)

Split off from PARTIAL, can be implemented separately but with inteactions
Several changes since -01, described in slide 3
New capability to enforce limits only on COPY/APPEND?
Barry: Don’t see need for separate capability. User just needs to be alerted that the server may not enforce the limit.
Phillip Tao: Having limits would be good for MUAs to know whether to use smaller batches
Ken Murchison: Phil may have changed his mind on this.
Barry: Will defer to actual client developers. Move already allows non-atomic, but copy and append need atomic.
Daniel: Concerned that client will break if it does things the server doesn’t allow like copying 11K vs 10K messages.
Barry: Some servers already enforce a limit and have no way to announce it.
Phillip: Concerned that implementing this without considering the impact on users will be a problem.

Several open issues re LIMIT (e.g., IMAP keyword limit)
Phillip: Clients may already understand limit that this may confuse.
Clients may still potentially break.
Phillip: This is also tied into ENABLE

MESSAGELIMIT application per-command may lead to inconsistencies. Make this ENABLE-able again?
Phillip: Not a lot of servers will return a partial fetch.
Alexey: Possibly publish this as experimental rather than standards-track?

Also need to consider CLOSE behavior wrt MESSAGELIMIT.
Barry: Hadn’t noticed EXPUNGE was part of this. Limiting the scope of EXPUNGE will be confusing.
Taking this issue to the list.

3)imap-uidonly - 5 min (Alexey)

No update.

4)sieve-processimip - 5 min (Ken Murchison)

Name changed to processcalendar
New :nonitip tagged argument
Now independent of iMIP, calendar data format agnostic.
Ready for last call after adding text to security considerations

5)sieve-snooze - 5 min (Ken Murchison)

Took content from Neil’s jmap snooze
New “snooze” mailbox attribute
syntax description (slide 4)
Issues with COPY or MOVE on Snoozed mailbox
Barry: Other special use mailbox types with similar limitation?
Ken: Not aware of any.
Barry: This is a new complication then.
Pete: As I said in jmap, this is icky. Prefer an annotation that goes with the message (rather than in the mailbox)
Barry: Generally agree with Pete.
Neil Jenkins: Countering Pete, Making things more generic makes things less interoperable. So we should constrain it.

6)RFC4549bis - 5 min (Alexey)

Typical size of mailboxes has grown considerably
FETCH 1:* (FLAGS) considered harmful
Next action: write a draft

## AOB
NONE