Minutes IETF117: extra
minutes-117-extra-00

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