@rapidmx/mapi-plugin 1.0.0-beta.3

package/dist/types/rop/RopDeleteMessagesHandler.d.ts

@@ -0,0 +1,31 @@
+import type { BufferReader, BufferWriter } from "../codec/BufferCursor.js";
+import type { RopContext, RopHandler } from "./RopHandler.js";
+/**
+ * `RopDeleteMessages` (`[MS-OXCMSG]`/`[MS-OXCROPS]`, RopId `0x1E`): deletes one or more messages by `MessageId`
+ * from an already-open folder handle. Reuses `RecoverableRepoUtils.delete()` exactly as-built in Phase 2 - the
+ * same soft-delete-with-watermark-bump machinery EAS's own `Sync`/`FolderSync` incremental-delete detection
+ * already relies on (see `BaseMapiEmsmdbRoute.ts`'s own doc comment for why `folderRepo`/`messageRepo`/
+ * `calendarEventRepo` are built as `RecoverableRepoUtils`, not plain `RepoUtils`) - no new deletion-tracking
+ * code, zero duplication.
+ *
+ * A `MessageId` resolves via `session.messageIds` (`MessageTarget.assignOrGetMid`'s own registry, already
+ * generic over both `"message:<uid>"` and `"calendarEvent:<uid>"` target strings, since a Calendar item is
+ * itself a Message object on the wire - see `CalendarEventTarget.ts`'s own doc comment) directly to the entity
+ * to delete, the same "the session already knows what this small integer refers to" design every other MID-
+ * consuming ROP in this pragmatic subset already uses (`RopOpenMessage`, `RopSaveChangesMessage`) - the
+ * request's own `InputHandleIndex` (nominally the messages' shared parent folder) is validated to be a real,
+ * open folder handle but not cross-checked against each message's actual `folderUid`, the same pragmatic
+ * simplification `RopOpenMessageHandler`'s own doc comment documents for its analogous `FolderId` field.
+ *
+ * `WantAsynchronous` (`RopProgress`-reported async completion) and `NotifyNonRead` (non-read-receipt generation
+ * to the original sender) are decoded to advance the reader correctly but not honored - this pragmatic subset
+ * has no async-ROP or non-read-receipt machinery. `PartialCompletion` is reported `true` if any requested
+ * `MessageId` didn't resolve to a real message/calendar-event target - the rest are still deleted, matching
+ * this pragmatic subset's "don't fail the whole ROP over one stale reference" principle used throughout.
+ *
+ * @author Jean-Philippe Steinmetz
+ */
+export declare class RopDeleteMessagesHandler implements RopHandler {
+    readonly ropId = 30;
+    handle(reader: BufferReader, writer: BufferWriter, context: RopContext): Promise<void>;
+}

package/dist/types/rop/RopFastTransferSourceCopyPropertiesHandler.d.ts

@@ -0,0 +1,24 @@
+import type { BufferReader, BufferWriter } from "../codec/BufferCursor.js";
+import type { RopContext, RopHandler } from "./RopHandler.js";
+/**
+ * `RopFastTransferSourceCopyProperties` (`[MS-OXCFXICS]`/`[MS-OXCROPS]`, RopId `0x69`): the explicit-column
+ * sibling of `RopFastTransferSourceCopyTo` - `PropertyTags` here is the properties to **copy** (an include
+ * list, per `[MS-OXCROPS]`'s own wording, the opposite of `CopyTo`'s exclude list), applied uniformly at both
+ * folder- and message-level wherever `FastTransferStream.ts` builds a `propList` - see that file's own doc
+ * comment for this pragmatic subset's overall ICS scope. An empty `PropertyTags` list is honored literally
+ * (copies zero properties, i.e. empty `propList`s) rather than falling back to `CopyTo`'s own default column
+ * set - that fallback belongs to `CopyTo` alone, since an explicit "copy nothing" request here is spec-valid
+ * and distinguishable from "use the default set" (`CopyTo` simply has no `PropertyTags`-supplied alternative to
+ * fall back from).
+ *
+ * `Level`/`CopyFlags`/`SendOptions` are decoded to advance the reader correctly but not honored - see
+ * `RopFastTransferSourceCopyToHandler`'s own doc comment for the identical reasoning. Note `CopyFlags` here is
+ * **1 byte**, not 4 like `CopyTo`'s own field of the same name - confirmed against each ROP's own request-buffer
+ * page separately, not assumed identical.
+ *
+ * @author Jean-Philippe Steinmetz
+ */
+export declare class RopFastTransferSourceCopyPropertiesHandler implements RopHandler {
+    readonly ropId = 105;
+    handle(reader: BufferReader, writer: BufferWriter, context: RopContext): Promise<void>;
+}

package/dist/types/rop/RopFastTransferSourceCopyToHandler.d.ts

@@ -0,0 +1,24 @@
+import type { BufferReader, BufferWriter } from "../codec/BufferCursor.js";
+import type { RopContext, RopHandler } from "./RopHandler.js";
+/**
+ * `RopFastTransferSourceCopyTo` (`[MS-OXCFXICS]`/`[MS-OXCROPS]`, RopId `0x4D`): begins a FastTransfer download
+ * of an already-open Folder or Message (or Calendar item, itself a Message object on the wire) object,
+ * producing a new `"fastTransfer"` Server object handle `RopFastTransferSourceGetBuffer` pages the built stream
+ * out of. See `FastTransferStream.ts`'s own doc comment for this pragmatic subset's "full, non-differential
+ * dump" ICS scope and its default property columns.
+ *
+ * `Level` (whether to recurse into subfolders) is decoded to advance the reader correctly but not honored -
+ * this pragmatic subset never recurses into subfolders regardless. `CopyFlags`/`SendOptions` (Move mode, best-
+ * body preference, Unicode preference, recoverable-mode, ...) are likewise decoded but not honored - this
+ * pragmatic subset always copies (never moves) and always encodes the same way regardless of client
+ * preference, matching `RopGetPropertiesSpecificHandler`'s own treatment of its analogous `WantUnicode` field.
+ * `PropertyTags` is the properties to *exclude* from the default column set (`[MS-OXCROPS]`'s own wording) -
+ * see `FastTransferStream.ts` for why an explicit include list instead is `RopFastTransferSourceCopyProperties`'s
+ * own job, not this ROP's.
+ *
+ * @author Jean-Philippe Steinmetz
+ */
+export declare class RopFastTransferSourceCopyToHandler implements RopHandler {
+    readonly ropId = 77;
+    handle(reader: BufferReader, writer: BufferWriter, context: RopContext): Promise<void>;
+}

package/dist/types/rop/RopFastTransferSourceGetBufferHandler.d.ts

@@ -0,0 +1,23 @@
+import type { BufferReader, BufferWriter } from "../codec/BufferCursor.js";
+import type { RopContext, RopHandler } from "./RopHandler.js";
+/**
+ * `RopFastTransferSourceGetBuffer` (`[MS-OXCFXICS]`/`[MS-OXCROPS]`, RopId `0x4E`): pages the FastTransfer
+ * stream a prior `RopFastTransferSourceCopyTo`/`CopyProperties` built (`FastTransferStream.ts`) out of its
+ * `"fastTransfer"` handle, `BufferSize` bytes at a time (or the entire remaining buffer, capped to
+ * `MAX_TRANSFER_BUFFER_SIZE`, for the `0xBABE` "server-determined" sentinel - `MaximumBufferSize`, present only
+ * in that case, is decoded to advance the reader correctly but not honored, since honoring it would mean
+ * returning *more* than one chunk can carry, not less). Reports `Done` once the whole buffer has been returned
+ * across one or more calls, `Partial` otherwise - `NoRoom` and `Error` are never produced (a `"fastTransfer"`
+ * handle, once created, always has a complete, already-valid buffer to page from).
+ *
+ * `BackoffTime` is never emitted (this pragmatic subset never returns the one `ReturnValue` that field is
+ * conditional on), and the failure path (`ERROR_INVALID_OBJECT`) omits every field after `ReturnValue` entirely
+ * - the same "just the fixed header, no success-only tail" shape every other failing handler in this pragmatic
+ * subset already uses, not a specific claim about the real spec's own error-path byte layout.
+ *
+ * @author Jean-Philippe Steinmetz
+ */
+export declare class RopFastTransferSourceGetBufferHandler implements RopHandler {
+    readonly ropId = 78;
+    handle(reader: BufferReader, writer: BufferWriter, context: RopContext): void;
+}

package/dist/types/rop/RopGetContentsTableHandler.d.ts

@@ -0,0 +1,31 @@
+import type { BufferReader, BufferWriter } from "../codec/BufferCursor.js";
+import type { RopContext, RopHandler } from "./RopHandler.js";
+/**
+ * `RopGetContentsTable` (`[MS-OXCFOLD]`/`[MS-OXCROPS]`): opens a table listing an already-opened folder's
+ * messages, producing a new `"table"` Server object handle `RopSetColumns`/`RopQueryRows` reference by
+ * `InputHandleIndex` - the exact same request/response shape as `RopGetHierarchyTable` (confirmed identical
+ * field-by-field against `[MS-OXCROPS]`'s own request-buffer page, differing only in `RopId`), just listing
+ * messages instead of child folders. `RopSetColumns`/`RopQueryRows` themselves need no changes at all to
+ * support this - they already operate generically on whatever `rows`/`columns` a table handle carries,
+ * dispatching to `FolderTarget`'s or `MessageTarget`'s resolvers by row-target prefix (`"folder:"`/`"virtual:"`
+ * vs `"message:"`).
+ *
+ * A folder's contents table is only ever non-empty for a real folder (`"folder:<uid>"`) - the virtual special
+ * folders (`RopLogonHandler`'s own doc comment) have no real backing row to hold messages under, so opening a
+ * contents table on one always yields an empty table rather than an error.
+ *
+ * **Calendar folders** (`Folder.type === FolderType.CALENDAR`) list `"calendarEvent:<uid>"` rows resolved via
+ * `calendarEventRepo` instead of `"message:<uid>"` rows - a single table handle only ever holds one kind of
+ * row, decided once here by checking the folder's own `type`, exactly the same "resolve by target-string
+ * prefix downstream" design `MessageTarget`/`FolderTarget` already use for their own rows. **Contacts and
+ * Tasks** folders (`FolderType.CONTACTS`/`TASKS`) list `"contact:<uid>"`/`"task:<uid>"` rows the same way, via
+ * `contactRepo`/`taskRepo` - empty (rather than an error) when the context has neither wired up, the same
+ * optional-repo degradation `RopContext`'s own doc comment describes.
+ *
+ * @author Jean-Philippe Steinmetz
+ */
+export declare class RopGetContentsTableHandler implements RopHandler {
+    readonly ropId = 5;
+    handle(reader: BufferReader, writer: BufferWriter, context: RopContext): Promise<void>;
+    private resolveRows;
+}

package/dist/types/rop/RopGetHierarchyTableHandler.d.ts

@@ -0,0 +1,17 @@
+import type { BufferReader, BufferWriter } from "../codec/BufferCursor.js";
+import type { RopContext, RopHandler } from "./RopHandler.js";
+/**
+ * `RopGetHierarchyTable` (`[MS-OXCFOLD]`/`[MS-OXCROPS]`): opens a table listing an already-opened folder's
+ * direct child folders, producing a new `"table"` Server object handle `RopSetColumns`/`RopQueryRows`
+ * reference by `InputHandleIndex`. Only `TableFlags = 0x00` ("Standard") is supported - this pragmatic subset
+ * has no deferred/async table population, so the immediate-row-count-returning variants some `TableFlags`
+ * values request are moot, and the response omits the row-count field those variants add (confirmed absent
+ * for the Standard case against `[MS-OXCROPS]`'s own request-buffer page, which explicitly lists `TableFlags`
+ * as this ROP's only request payload beyond the common handle-index header).
+ *
+ * @author Jean-Philippe Steinmetz
+ */
+export declare class RopGetHierarchyTableHandler implements RopHandler {
+    readonly ropId = 4;
+    handle(reader: BufferReader, writer: BufferWriter, context: RopContext): Promise<void>;
+}

package/dist/types/rop/RopGetPropertiesSpecificHandler.d.ts

@@ -0,0 +1,23 @@
+import type { BufferReader, BufferWriter } from "../codec/BufferCursor.js";
+import type { RopContext, RopHandler } from "./RopHandler.js";
+/**
+ * `RopGetPropertiesSpecific` (`[MS-OXCPRPT]`/`[MS-OXCROPS]`): fetches named property values for a single
+ * already-opened Folder or Message object (`RopOpenFolder`/`RopOpenMessage`), by an explicit `PropertyTags`
+ * list - the single-object analog of `RopQueryRows`' per-row column fetch, reusing the exact same
+ * `PropertyResolvers` value-resolution logic (a folder/message handle's `entityUid` is already the same
+ * `"folder:"`/`"virtual:"`/`"message:"` target-string format a table row uses). Like `RopQueryRows`, this
+ * pragmatic subset always emits a `StandardPropertyRow` (`Flags = 0x00`, confirmed as the response's `RowData`
+ * format via `[MS-OXCROPS]`'s own "Success Response Buffer" page, which names `[MS-OXCDATA]` §2.8's
+ * `PropertyRow` structure directly) - an unsupported property falls back to a type-appropriate default rather
+ * than a `FlaggedPropertyRow`'s per-column error signaling, exactly as `RopQueryRows` already does.
+ *
+ * `PropertySizeLimit`/`WantUnicode` are decoded (to advance the reader correctly) but not honored - this
+ * pragmatic subset never truncates a property value and always encodes strings the same way regardless of the
+ * client's Unicode preference (see `PropertyValue.ts`'s own string-encoding doc comments).
+ *
+ * @author Jean-Philippe Steinmetz
+ */
+export declare class RopGetPropertiesSpecificHandler implements RopHandler {
+    readonly ropId = 7;
+    handle(reader: BufferReader, writer: BufferWriter, context: RopContext): Promise<void>;
+}

package/dist/types/rop/RopGetPropertyIdsFromNamesHandler.d.ts

@@ -0,0 +1,23 @@
+import type { BufferReader, BufferWriter } from "../codec/BufferCursor.js";
+import type { RopContext, RopHandler } from "./RopHandler.js";
+/**
+ * `RopGetPropertyIdsFromNames` (`[MS-OXCPRPT]`/`[MS-OXCROPS]` §2.2.8.1): resolves a list of named properties
+ * (`PropertyName` structures - a property-set `GUID` plus a numeric `LID` or string `Name`) into numeric
+ * property IDs a subsequent `RopSetProperties`/`RopGetPropertiesSpecific`/`RopQueryRows` call can use directly.
+ * This is the mechanism almost every Calendar-specific property (`PidLidAppointmentStartWhole`,
+ * `PidLidBusyStatus`, `PidLidAppointmentRecur`, ...) requires, since none of them have a fixed numeric
+ * `PidTag*`-style ID the way `PidTagSubject` does - see `NamedPropertyRegistry.ts`'s own doc comment for the
+ * session-scoped registry this delegates to.
+ *
+ * An unresolvable `PropertyName` (`Kind = 0xFF`) maps to `0x0000` in the response, per spec - this pragmatic
+ * subset has no other unmappable case (no permission/quota/hard-limit checks), so every `Kind = 0x00`/`0x01`
+ * entry always succeeds. `Flags` is decoded to advance past it correctly but not honored - see
+ * `assignOrGetNamedPropertyId`'s own doc comment for why "probe" and "assign" collapse to the same behavior
+ * for a purely session-scoped registry.
+ *
+ * @author Jean-Philippe Steinmetz
+ */
+export declare class RopGetPropertyIdsFromNamesHandler implements RopHandler {
+    readonly ropId = 86;
+    handle(reader: BufferReader, writer: BufferWriter, context: RopContext): void;
+}

package/dist/types/rop/RopHandler.d.ts

@@ -0,0 +1,67 @@
+import type { RepoUtils } from "@rapidrest/service-core";
+import type { BlobStore } from "@rapidmx/restapi";
+import type { ScanPipeline } from "@rapidmx/restapi/scan";
+import type { BufferReader, BufferWriter } from "../codec/BufferCursor.js";
+import type { MapiSessionContext } from "../MapiSessionManager.js";
+/**
+ * Everything a `RopHandler` needs beyond the raw ROP bytes it decodes itself. `folderRepo`/`mailboxRepo` are
+ * built once by `BaseMapiEmsmdbRoute` (not by each handler, unlike EAS's per-command repo pattern - MAPI's ROPs
+ * are far more tightly interdependent around the same few entity types than EAS's per-command-collection-type
+ * structure was, so centralizing the common repos here avoids every handler rebuilding its own). Untyped as
+ * `RepoUtils<any>` rather than a generic `F extends Folder` parameter threaded through every handler file -
+ * the same pragmatic `any` this codebase already uses throughout for `xxxClass`/`xxxRepo` DI fields, since
+ * `RepoUtils<F>`'s method contravariance makes a generic version genuinely awkward for no real benefit here
+ * (every handler only ever reads `Folder`-shaped rows, never constructs backend-specific entities itself).
+ *
+ * `folderClass`/`messageClass` (the concrete Mongo/SQL entity constructors) are threaded through here rather
+ * than held as a field on each handler - unlike EAS's `EasCommandHandler`s, a single shared `RopHandler`
+ * instance (e.g. `RopSubmitMessageHandler`) is reused for *both* the Mongo and SQL route (`ropHandlerClasses`
+ * lists the exact same classes in `MapiEmsmdbRouteMongo`/`SQL`), so the concrete class can only ever be known
+ * per-request, via this context - needed by `RopSubmitMessageHandler`'s `findOrCreateWellKnownFolder()`/
+ * `messageRepo.create()` calls when persisting a submitted message's Sent Items copy. `scanPipeline`/
+ * `mailTransport` back the same `scanAndRelay()` compose/send pipeline `BaseMessageRoute.send()`/EAS's
+ * `ComposeMailCommand` already share via `MailSendUtils.ts`.
+ *
+ * `contactRepo`/`taskRepo`/`contactClass`/`taskClass`/`labelRepo`/`labelClass` are **optional**, unlike every
+ * other repo/class pair here - `BaseMapiEmsmdbRoute` always populates them in real use (see its own `@Init`),
+ * but making them required would force every one of this codebase's many existing `RopContext`-literal test
+ * fixtures (most predating Contacts/Tasks folder support, and all predating Label support) to grow new fields
+ * each for no behavioral reason. Every consumer (`PropertyResolvers.ts`, `RopGetContentsTableHandler.ts`,
+ * `RopOpenMessageHandler.ts`) already degrades a `"contact:"`/`"task:"` target to empty/no-rows when the
+ * corresponding repo is absent, the same "missing data, not a crash" stance `resolveContactInfo`/
+ * `resolveTaskInfo` take for a vanished row; `labelRepo` absent degrades `PidNameKeywords` (Outlook Categories)
+ * to an empty list the same way.
+ */
+export interface RopContext {
+    mailboxUid: string;
+    userUid: string;
+    session: MapiSessionContext;
+    mailboxRepo: RepoUtils<any>;
+    folderRepo: RepoUtils<any>;
+    messageRepo: RepoUtils<any>;
+    calendarEventRepo: RepoUtils<any>;
+    contactRepo?: RepoUtils<any>;
+    taskRepo?: RepoUtils<any>;
+    labelRepo?: RepoUtils<any>;
+    folderClass: any;
+    messageClass: any;
+    calendarEventClass: any;
+    contactClass?: any;
+    taskClass?: any;
+    labelClass?: any;
+    blobStore: BlobStore;
+    scanPipeline: ScanPipeline;
+    mailTransport: any;
+}
+/**
+ * One class per ROP, mirroring `EasCommandHandler`'s exact one-class-per-command convention. A handler owns
+ * its own request/response wire format entirely - decoding whatever fields follow its own `RopId` byte from
+ * `reader` (already consumed by the dispatcher) and appending its response bytes (if any - `RopRelease`
+ * intentionally appends none) to the shared `writer`. See `RopBuffer.ts`'s doc comment for why a generic
+ * dispatcher can't do this decoding itself.
+ */
+export interface RopHandler {
+    /** The `RopId` byte this handler processes (e.g. `0xFE` for `RopLogon`). */
+    readonly ropId: number;
+    handle(reader: BufferReader, writer: BufferWriter, context: RopContext): Promise<void> | void;
+}

package/dist/types/rop/RopLogonHandler.d.ts

@@ -0,0 +1,31 @@
+import { BufferReader, BufferWriter } from "../codec/BufferCursor.js";
+import type { RopContext, RopHandler } from "./RopHandler.js";
+/**
+ * `RopLogon` (`[MS-OXCSTOR]`/`[MS-OXCROPS]`): the first ROP of any session, a prerequisite for every other
+ * ROP. This pragmatic subset always performs a private-mailbox logon against the mailbox `BaseMapiEmsmdbRoute`
+ * already resolved and authorized at `Connect` time - the request's own `Essdn` field is decoded (to advance
+ * past it correctly) but never trusted for mailbox identity, the same principle `BaseMapiEmsmdbRoute.Connect`
+ * already applies to that request's `UserDn` field. Because mailbox resolution already happened upstream,
+ * this handler has no real failure path to model (`ecUnknownUser`/`ecLoginFailure`/... are all deferred).
+ *
+ * @author Jean-Philippe Steinmetz
+ */
+export declare class RopLogonHandler implements RopHandler {
+    readonly ropId = 254;
+    handle(reader: BufferReader, writer: BufferWriter, context: RopContext): Promise<void>;
+    /**
+     * Assigns this session's FIDs for the 13 special folders, remembering each one's real-`Folder`-or-virtual-
+     * placeholder target in `session.folderIds` so a later `RopOpenFolder` can resolve it back to something
+     * real. Delegates to `FolderTarget.assignOrGetFid` - the same "reuse an existing FID for this target if one
+     * was already assigned, otherwise mint the next free one" logic `RopGetHierarchyTable`/`RopQueryRows` use
+     * for child folders - rather than wholesale-replacing `session.folderIds` with a freshly-numbered map
+     * starting back at FID 1. A second `RopLogon` on a live session (spec-legal - a real client can reconnect
+     * or re-logon within one session context) previously invalidated every FID a client had already learned
+     * for a child folder via `RopGetHierarchyTable`/`RopQueryRows` (all assigned starting at FID 14, since the
+     * old code always reset the counter to 1-13 for just these specials) and could even cause FIDs 14+ to be
+     * silently re-issued to a *different* folder than the one the client last associated with that number.
+     * Reusing `assignOrGetFid` means a re-`RopLogon` is now purely additive: these 13 targets get their
+     * existing FIDs back if this is a second logon, and any child-folder FIDs already assigned are left alone.
+     */
+    private assignFolderIds;
+}

package/dist/types/rop/RopOpenFolderHandler.d.ts

@@ -0,0 +1,19 @@
+import type { BufferReader, BufferWriter } from "../codec/BufferCursor.js";
+import type { RopContext, RopHandler } from "./RopHandler.js";
+/**
+ * `RopOpenFolder` (`[MS-OXCFOLD]`/`[MS-OXCROPS]`): opens a folder by FID, producing a new `"folder"` Server
+ * object handle later ROPs (`RopGetHierarchyTable`, a future `RopGetContentsTable`) reference by
+ * `InputHandleIndex`. The request's own `OpenModeFlags` (`OpenSoftDeleted`, ...) is decoded to advance past
+ * it correctly but not acted on - this pragmatic subset has no soft-deleted-folder recovery flow.
+ *
+ * Private-mailbox-only response shape: `IsGhosted` is always `0` and its conditional
+ * `ServerCount`/`CheapServerCount`/`Servers` fields are never present, since `IsGhosted` and its trailing
+ * fields are documented as public-folder-only (`[MS-OXCFOLD]`'s own "RopOpenFolder ROP Response Buffer"
+ * page). `HasRules` is always `0` - this library has no `[MS-OXORULE]` rules-engine support.
+ *
+ * @author Jean-Philippe Steinmetz
+ */
+export declare class RopOpenFolderHandler implements RopHandler {
+    readonly ropId = 2;
+    handle(reader: BufferReader, writer: BufferWriter, context: RopContext): void;
+}

package/dist/types/rop/RopOpenMessageHandler.d.ts

@@ -0,0 +1,27 @@
+import type { BufferReader, BufferWriter } from "../codec/BufferCursor.js";
+import type { RopContext, RopHandler } from "./RopHandler.js";
+/**
+ * `RopOpenMessage` (`[MS-OXCMSG]`/`[MS-OXCROPS]`): opens a message by MID, producing a new `"message"` Server
+ * object handle later ROPs (`RopGetPropertiesSpecific`, `RopOpenStream`) reference by `InputHandleIndex`. The
+ * request's own `FolderId` (the message's expected parent folder) and `CodePageId` are decoded to advance past
+ * them correctly but not otherwise acted on - a MID is resolved directly via `session.messageIds`
+ * (`MessageTarget.assignOrGetMid`), the same "the session already knows what this small integer refers to"
+ * design `RopOpenFolderHandler` uses for FIDs, so cross-checking the caller-supplied `FolderId` would be pure
+ * redundancy. `OpenModeFlags` is likewise decoded but not honored - this pragmatic subset only ever opens a
+ * message for reading (no `RopSetProperties`/`RopSaveChangesMessage` write-back support yet).
+ *
+ * **Pragmatic success response**: `HasNamedProperties` is always `false` - a conservative hint value only, not
+ * a claim that named properties are unsupported (`RopGetPropertyIdsFromNames`/`PropertyResolvers.ts` do resolve
+ * them for a subsequently-opened Calendar item; a real client calls `RopGetPropertyIdsFromNames` unconditionally
+ * for a known Calendar message class regardless of this flag, so leaving it `false` doesn't block that path).
+ * The `SubjectPrefix`/`NormalizedSubject` `TypedString`s are "no prefix" + the item's plain subject/title (this
+ * data model has no separate prefix/normalized-subject split the way real Exchange does), and the recipient
+ * table (`RecipientCount`/`ColumnCount`/`RecipientColumns`/`RowCount`/`RecipientRows`) is always empty - reading
+ * a message's `To`/`Cc` list is a documented gap in this pass, not silently wrong data.
+ *
+ * @author Jean-Philippe Steinmetz
+ */
+export declare class RopOpenMessageHandler implements RopHandler {
+    readonly ropId = 3;
+    handle(reader: BufferReader, writer: BufferWriter, context: RopContext): Promise<void>;
+}

package/dist/types/rop/RopOpenStreamHandler.d.ts

@@ -0,0 +1,27 @@
+import type { BufferReader, BufferWriter } from "../codec/BufferCursor.js";
+import type { RopContext, RopHandler } from "./RopHandler.js";
+/**
+ * `RopOpenStream` (`[MS-OXCPRPT]`/`[MS-OXCROPS]`): opens a property for streaming access, producing a new
+ * `"stream"` Server object handle `RopReadStream`/`RopWriteStream` reads/writes by `InputHandleIndex`.
+ * **Pragmatic subset**: only `PidTagBody` (`PtypString`, the plain-text message body) on a `"message"` handle
+ * is supported - a real client also streams `PidTagHtml`/`PidTagRtfCompressed` (rich body formats) and
+ * folder/attachment binary properties, none of which this pass implements; requesting any other `PropertyTag`,
+ * or opening a stream against a non-message handle, fails with `MAPI_E_NOT_FOUND` rather than succeeding with
+ * wrong data.
+ *
+ * `OpenModeFlags` (`[MS-OXCPRPT]` §2.2.14.1) selects which of two independent code paths runs:
+ * - `ReadOnly` (`0x00`): the step-7 behavior - resolves the real, already-saved message's body via
+ * `MessageBodyStream.resolveMessageBodyBytes()` (`BlobStore` + `mailparser`) and reports its length as
+ * `StreamSize`, for `RopReadStream` to read back.
+ * - `ReadWrite`/`Create` (`0x01`/`0x02`): a **write-mode** stream, the step-8 addition compose/send needs to
+ * accept a message body via `RopWriteStream` - `StreamSize` is always `0` (matching `Create`'s "discards the
+ * existing value" semantics; this pragmatic subset never opens `ReadWrite` against a body that already has
+ * content) and the new handle's `writeTargetHandleIndex` remembers which message handle to write back into,
+ * the link `RopWriteStream`/`RopSaveChangesMessageHandler`/`RopSubmitMessageHandler` use to find it again.
+ *
+ * @author Jean-Philippe Steinmetz
+ */
+export declare class RopOpenStreamHandler implements RopHandler {
+    readonly ropId = 43;
+    handle(reader: BufferReader, writer: BufferWriter, context: RopContext): Promise<void>;
+}

package/dist/types/rop/RopQueryRowsHandler.d.ts

@@ -0,0 +1,36 @@
+import { BufferReader, BufferWriter } from "../codec/BufferCursor.js";
+import type { RopContext, RopHandler } from "./RopHandler.js";
+/**
+ * `RopQueryRows` (`[MS-OXCTABL]`/`[MS-OXCROPS]`): fetches up to `RowCount` rows from an already-configured
+ * table (`RopGetHierarchyTable` + `RopSetColumns`), advancing the table's cursor. Confirmed field-by-field
+ * against `[MS-OXCTABL]`'s own real captured request/response byte example - including the response's
+ * `RowData` encoding (`PropertyRow`: a leading `Flags` byte, `0x00` for a `StandardPropertyRow` where every
+ * column is a plain `PropertyValue`, `0x01` for a `FlaggedPropertyRow` where each column gets its own
+ * `FlaggedPropertyValue` flag+optional-value). This pragmatic subset always emits `StandardPropertyRow`
+ * (`Flags = 0x00`) - every configured column always resolves to *some* value here (falling back to a
+ * type-appropriate zero/empty default for an unsupported property, never an error), so `FlaggedPropertyRow`'s
+ * per-column error signaling is never needed.
+ *
+ * Backward reads (`ForwardRead = FALSE`) and the `NoAdvance` flag are decoded (to advance the reader
+ * correctly) but not honored - this pragmatic subset's tables are simple forward-only cursors. Works generically
+ * against either a `RopGetHierarchyTable` (folder rows, `"folder:"`/`"virtual:"` targets) or a
+ * `RopGetContentsTable` (message rows, `"message:"` targets) handle - dispatching to `FolderTarget`'s or
+ * `MessageTarget`'s resolver and property-value mapping by row-target prefix, since a single table handle only
+ * ever holds one kind of row.
+ *
+ * **Known, deliberate performance limitation**: `resolvePropertyValues` still does one `repo.findOne()` per
+ * row (message/calendarEvent/contact/task) rather than a single batched fetch for the whole page - a genuine
+ * N+1 for a large `RowCount`. A real fix needs a batched "fetch all these uids" query, which this codebase's
+ * `RepoUtils<T>` abstraction doesn't expose a backend-agnostic way to express (Mongo's `$in` and TypeORM's
+ * `In()` aren't interchangeable at this call site, which has no idea which backend it's running against) - see
+ * `ResolutionCache` for the narrower, safe win this pass *did* make (the redundant *identical* whole-mailbox-
+ * folder-list and calendar-mailbox fetches that were happening once per row regardless of which distinct
+ * entity each row was, now happen at most once per call).
+ *
+ * @author Jean-Philippe Steinmetz
+ */
+export declare class RopQueryRowsHandler implements RopHandler {
+    readonly ropId = 21;
+    handle(reader: BufferReader, writer: BufferWriter, context: RopContext): Promise<void>;
+    private buildRow;
+}

package/dist/types/rop/RopReadStreamHandler.d.ts

@@ -0,0 +1,18 @@
+import type { BufferReader, BufferWriter } from "../codec/BufferCursor.js";
+import type { RopContext, RopHandler } from "./RopHandler.js";
+/**
+ * `RopReadStream` (`[MS-OXCPRPT]`/`[MS-OXCROPS]`): reads up to `ByteCount` (or `MaximumByteCount`, if
+ * `ByteCount` is the `0xBABE` sentinel) bytes from an already-opened stream (`RopOpenStream`), advancing the
+ * stream's read position - clamped to `MAX_DATA_SIZE` (`0xFFFF`) regardless of what the client asked for, since
+ * the response's own `DataSize` field can't carry more than that; a client wanting more of a large body simply
+ * calls `RopReadStream` again from the advanced `streamPosition`, the same paging behavior real Exchange uses.
+ * Unlike most other ROPs in this pragmatic subset, `[MS-OXCROPS]` documents only one combined response-buffer
+ * shape for this ROP (no separate Success/Failure pages) - `DataSize`/`Data` are always present, `DataSize = 0`
+ * (empty `Data`) standing in for the failure case rather than the fields being omitted entirely.
+ *
+ * @author Jean-Philippe Steinmetz
+ */
+export declare class RopReadStreamHandler implements RopHandler {
+    readonly ropId = 44;
+    handle(reader: BufferReader, writer: BufferWriter, context: RopContext): Promise<void>;
+}

package/dist/types/rop/RopReleaseHandler.d.ts

@@ -0,0 +1,14 @@
+import type { BufferReader, BufferWriter } from "../codec/BufferCursor.js";
+import type { RopContext, RopHandler } from "./RopHandler.js";
+/**
+ * `RopRelease` (`[MS-OXCROPS]`): releases a Server object handle. Confirmed against the spec's own real
+ * captured example (`08 00 01 00 00 01 00 01 6F 00 00 00 6E 00 00 00`) that the request is exactly 3 bytes
+ * (`RopId`/`LogonId`/`InputHandleIndex`) and, uniquely among ROPs, **produces no response entry at all** - the
+ * server MUST NOT write anything to the output buffer for it, so `handle()` never touches `writer`.
+ *
+ * @author Jean-Philippe Steinmetz
+ */
+export declare class RopReleaseHandler implements RopHandler {
+    readonly ropId = 1;
+    handle(reader: BufferReader, _writer: BufferWriter, context: RopContext): void;
+}

package/dist/types/rop/RopSaveChangesMessageHandler.d.ts

@@ -0,0 +1,44 @@
+import { BufferReader, type BufferWriter } from "../codec/BufferCursor.js";
+import type { RopContext, RopHandler } from "./RopHandler.js";
+/**
+ * `RopSaveChangesMessage` (`[MS-OXCMSG]`/`[MS-OXCROPS]`): persists a message's pending changes, returning the
+ * `MID` a client can reference it by afterwards. **Pragmatic subset**: this library has no separate Drafts-
+ * folder persistence step (matching EAS's own `ComposeMailCommand`, which never creates a standalone draft
+ * `Message` row either) - saving a `RopCreateMessage` draft does not yet write anything to a database. It only
+ * assigns a session-scoped MID (`MessageTarget.assignOrGetMid`, the exact mechanism a `RopQueryRows` row's
+ * `PidTagMid` column already uses) so the wire contract's `MessageId` field is well-formed, keyed by this
+ * handle's own index (`` `draft:${inputHandleIndex}` ``) since an unsaved draft has no real `"message:<uid>"`
+ * target yet. The real work - actually building and sending a MIME message from the properties/body
+ * accumulated so far - happens at `RopSubmitMessage` time, not here; calling Save without ever calling Submit
+ * silently discards the draft when the session expires, a real, deliberate limitation (this pragmatic subset
+ * has no autosave-recovery story) rather than a silently-wrong one.
+ *
+ * Re-saving an already-real message (a `RopOpenMessage` handle, not a fresh `RopCreateMessage` draft) is
+ * accepted but is a no-op beyond echoing that message's own already-assigned MID - editing an existing
+ * message's properties is out of scope for this pragmatic subset's compose/send-only ROP coverage.
+ *
+ * `SaveFlags` is decoded to advance past it correctly but not honored - this pragmatic subset has no
+ * conflict-resolution/force-save semantics to vary by flag.
+ *
+ * **Calendar branch**: unlike mail, a draft whose `PidTagMessageClass` starts with `"IPM.Appointment"` *is*
+ * durably persisted here (`saveAppointment()`) - creating (or updating, if this handle already refers to a real
+ * `"calendarEvent:<uid>"`) a real `CalendarEvent` row, so a subsequent `RopGetPropertiesSpecific` can read it
+ * back before `RopSubmitMessage` is ever called (a calendar item must exist as soon as it's saved, the same way
+ * a real Exchange server behaves - unlike a mail draft, which this pragmatic subset never persists at all until
+ * Submit).
+ *
+ * @author Jean-Philippe Steinmetz
+ */
+export declare class RopSaveChangesMessageHandler implements RopHandler {
+    readonly ropId = 12;
+    handle(reader: BufferReader, writer: BufferWriter, context: RopContext): Promise<void>;
+    /**
+     * Persists (creating, or updating an already-real one) a `CalendarEvent` from the draft's accumulated
+     * `RopSetProperties` values, and returns the MID a client can reference it by. Every field this pragmatic
+     * subset understands (per `CalendarNamedProperties.ts`) is decoded via `decodeCalendarFieldsFromDraft`
+     * below - the write-side mirror of `PropertyResolvers.calendarEventValueFor`'s read-side switch. A field the
+     * client never set (e.g. no `RopSetProperties` call touched `PidLidBusyStatus`) falls back to the existing
+     * row's own value on an update, or the entity class's own default on a fresh create.
+     */
+    private saveAppointment;
+}

package/dist/types/rop/RopSetColumnsHandler.d.ts

@@ -0,0 +1,21 @@
+import type { BufferReader, BufferWriter } from "../codec/BufferCursor.js";
+import type { RopContext, RopHandler } from "./RopHandler.js";
+/**
+ * `RopSetColumns` (`[MS-OXCTABL]`/`[MS-OXCROPS]`): configures which properties a table's subsequent
+ * `RopQueryRows` calls return, and in what order. Unlike `RopOpenFolder`/`RopGetHierarchyTable`, this ROP
+ * doesn't create a new handle - it mutates the existing table handle referenced by `InputHandleIndex` in
+ * place, so its response echoes `InputHandleIndex` rather than an `OutputHandleIndex`, the same convention
+ * `RopQueryRows`' own response uses (confirmed against `[MS-OXCTABL]`'s real captured response example).
+ *
+ * Validates that `InputHandleIndex` actually refers to a `"table"` handle before mutating it, the same check
+ * every other handle-consuming ROP in this pragmatic subset already makes - a missing or wrong-type handle
+ * previously fell through silently (no `else` branch) to a bare success response, meaning a client that set
+ * columns against a stale/released/wrong-kind handle index only discovered the real problem one ROP later,
+ * when `RopQueryRows` on that same index returned `MAPI_E_INVALID_OBJECT` instead.
+ *
+ * @author Jean-Philippe Steinmetz
+ */
+export declare class RopSetColumnsHandler implements RopHandler {
+    readonly ropId = 18;
+    handle(reader: BufferReader, writer: BufferWriter, context: RopContext): void;
+}

package/dist/types/rop/RopSetPropertiesHandler.d.ts

@@ -0,0 +1,38 @@
+import type { BufferReader, BufferWriter } from "../codec/BufferCursor.js";
+import type { RopContext, RopHandler } from "./RopHandler.js";
+/** `PidTagReadReceiptRequested` (`PT_BOOLEAN`) - a client checking "Request a read receipt" before Submit sets
+ * this; `RopSubmitMessageHandler` reads it back to attach a real `Disposition-Notification-To` header, mirroring
+ * `BaseMessageRoute.send()`'s own explicit-`Message.requestReceipt` handling (see `util/ReceiptUtils.ts`). */
+export declare const PID_TAG_READ_RECEIPT_REQUESTED = 41;
+/** `PidTagDeferredSendTime` (`PT_SYSTIME`) - real Outlook's "Do not deliver before" compose option;
+ * `RopSubmitMessageHandler` reads it back to defer relay exactly like `BaseMessageRoute.send()`'s own
+ * `Message.scheduledSendTime` branch does (moving the message to Outbox for `ScheduledSendJob` to relay later)
+ * instead of sending immediately. */
+export declare const PID_TAG_DEFERRED_SEND_TIME = 16367;
+/**
+ * `RopSetProperties` (`[MS-OXCPRPT]`/`[MS-OXCROPS]`): sets an explicit, client-chosen list of properties
+ * (`TaggedPropertyValue`s, each carrying its own `PropertyTag`) on an already-open object. This pragmatic
+ * subset supports only `"message"` handles (a `RopCreateMessage` draft, or an already-open `RopOpenMessage`
+ * handle) and only tracks the small property set `TRACKED_PROPERTY_IDS`/`TRACKED_APPOINTMENT_LIDS`/
+ * `TRACKED_COMMON_LIDS` name - see those constants' own comments for why. A named property (ID `>= 0x8000`) is
+ * resolved back to its `(PropertySet GUID, LID)` identity via `resolveNamedProperty` before it can be tracked,
+ * since MAPI has no fixed numeric ID for any Calendar property the way `PidTagSubject` has one.
+ *
+ * Every value is coerced to a plain string via `stringifyValue` before being stored in `handle.draftProperties`
+ * (itself a `Record<string, string>` for `MapiSessionContext`'s own JSON-safety reasons, see
+ * `MapiSessionManager.ts`) - a lossless, type-aware encoding (ISO-8601 for `PtypTime`, base64 for `PtypBinary`,
+ * plain `String()` otherwise) so `RopSaveChangesMessageHandler` can decode a Calendar item's properties back
+ * into a real `CalendarEvent`'s typed fields, not just display strings.
+ *
+ * Always reports success with zero `PropertyProblems`, even for a property this pragmatic subset doesn't
+ * track - the same "never fail over an unsupported property" pragmatic stance `RopQueryRows`/
+ * `RopGetPropertiesSpecific` already take (falling back to a default value there; simply not tracking the
+ * property here, since there is no row to fill in for a *set* operation).
+ *
+ * @author Jean-Philippe Steinmetz
+ */
+export declare class RopSetPropertiesHandler implements RopHandler {
+    readonly ropId = 10;
+    handle(reader: BufferReader, writer: BufferWriter, context: RopContext): void;
+    private isTrackedNamedProperty;
+}