Skip to content

Commit 8cb79de

Browse files
author
ietf-corpus-bot
committed
auto-ingest: ietf-elements backfill — 259 new elements (2026-07-05)
1 parent dfbab4c commit 8cb79de

259 files changed

Lines changed: 2392 additions & 0 deletions

File tree

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.
Lines changed: 9 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,9 @@
1+
document: rfc-8621
2+
kind: design-rationale
3+
summary: The Email object provides three flat body part lists (textBody, htmlBody, attachments) alongside the full bodyStructure MIME tree because flattening MIME for presentation is complex, error-prone, and causes inconsistency between clients. Standardizing this decomposition server-side reduces client implementation burden and improves consistency.
4+
section: "4.1"
5+
topics:
6+
- email
7+
- json
8+
extracted_by: claude-sonnet-4-6
9+
extracted_at: "2026-07-05"
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,9 @@
1+
document: rfc-8621
2+
kind: design-rationale
3+
summary: The 'maxSizeAttachmentsPerEmail' capability uses unencoded attachment sizes (as seen on disk) rather than encoded MIME sizes because users understand and are marketed to with unencoded sizes. This allows clients to enforce the limit in terms the user already understands, even though the actual MIME message may be larger due to base64 encoding.
4+
section: 1.3.1
5+
topics:
6+
- email
7+
- json
8+
extracted_by: claude-sonnet-4-6
9+
extracted_at: "2026-07-05"
Lines changed: 9 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,9 @@
1+
document: rfc-8621
2+
kind: design-rationale
3+
summary: The separate 'EmailDelivery' push type exists so battery-constrained clients can register for new-message notifications only, avoiding wake-ups for state changes such as marking messages read. It has no associated API methods; it exists solely as a push signal.
4+
section: "1.5"
5+
topics:
6+
- email
7+
- json
8+
extracted_by: claude-sonnet-4-6
9+
extracted_at: "2026-07-05"
Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,8 @@
1+
document: rfc-8621
2+
kind: design-rationale
3+
summary: 'The unreadThreads count for the trash mailbox uses special rules: emails only in trash are excluded from other mailboxes'' counts, and non-trash emails are excluded from the trash count. This treats trash emails as logically separate for unread-count purposes, matching expected client UI behavior when users delete one message from a thread.'
4+
section: "2"
5+
topics:
6+
- email
7+
extracted_by: claude-sonnet-4-6
8+
extracted_at: "2026-07-05"
Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,8 @@
1+
document: rfc-8621
2+
kind: interoperability-note
3+
summary: If the JMAP server also provides an IMAP interface and supports the IMAP Extension for Object Identifiers (RFC 8474), the ids SHOULD be the same for Mailbox, Thread, and Email objects across both protocols.
4+
section: "1.6"
5+
topics:
6+
- email
7+
extracted_by: claude-sonnet-4-6
8+
extracted_at: "2026-07-05"
Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,8 @@
1+
document: rfc-8621
2+
kind: interoperability-note
3+
summary: JMAP Email keywords are shared with IMAP. The four IMAP system flags (\Draft, \Seen, \Flagged, \Answered) are exposed in JMAP with a '$' prefix instead of '\'. The IMAP \Recent and \Deleted keywords are not exposed via JMAP; JMAP uses a destroy model rather than IMAP's delete+expunge model.
4+
section: 4.1.1
5+
topics:
6+
- email
7+
extracted_by: claude-sonnet-4-6
8+
extracted_at: "2026-07-05"
Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,8 @@
1+
document: rfc-8621
2+
kind: interoperability-note
3+
summary: The data model is designed for concurrent IMAP (RFC 3501) and JMAP access to the same mail store. Mailbox roles are shared with IMAP SPECIAL-USE (RFC 6154), but JMAP enforces stricter constraints (at most one role per mailbox, at most one mailbox per role per account).
4+
section: "2"
5+
topics:
6+
- email
7+
extracted_by: claude-sonnet-4-6
8+
extracted_at: "2026-07-05"
Lines changed: 10 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,10 @@
1+
document: rfc-8621
2+
kind: normative-requirement
3+
summary: A Mailbox MUST only have a single role, and there MUST NOT be two Mailboxes in the same account with the same role. Role values MUST be lowercase versions of names in the IANA 'IMAP Mailbox Name Attributes' registry.
4+
section: "2"
5+
rfc2119_level: MUST
6+
topics:
7+
- email
8+
- registry
9+
extracted_by: claude-sonnet-4-6
10+
extracted_at: "2026-07-05"
Lines changed: 10 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,10 @@
1+
document: rfc-8621
2+
kind: normative-requirement
3+
summary: A user may only modify the '$seen' keyword on an Email if they have 'maySetSeen' permission for ALL Mailboxes that contain that Email. Other keyword modifications require 'maySetKeywords' permission for all containing Mailboxes.
4+
section: "2"
5+
rfc2119_level: MUST
6+
topics:
7+
- email
8+
- security
9+
extracted_by: claude-sonnet-4-6
10+
extracted_at: "2026-07-05"
Lines changed: 10 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,10 @@
1+
document: rfc-8621
2+
kind: normative-requirement
3+
summary: An Email MUST belong to one or more Mailboxes at all times until it is destroyed. The Email id does not change if the Email moves between Mailboxes.
4+
section: "2"
5+
rfc2119_level: MUST
6+
topics:
7+
- email
8+
- json
9+
extracted_by: claude-sonnet-4-6
10+
extracted_at: "2026-07-05"

0 commit comments

Comments
 (0)