@rapidmx/mapi-plugin 1.0.0-beta.10

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

@@ -0,0 +1,25 @@
+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;
+    readonly responseHandleIndexOffset = 3;
+    handle(reader: BufferReader, writer: BufferWriter, context: RopContext): Promise<void>;
+}

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

@@ -0,0 +1,22 @@
+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. For the `0xBABE` "server-determined" sentinel the server
+ * picks the size, up to the client's `MaximumBufferSize`.
+ *
+ * Every chunk is also held to the room left in this request's ROP output buffer (`context.ropOutputRemaining`) and
+ * the 16-bit `TransferBufferSize`. Reports `Done` once the whole stream has been returned, `Partial` otherwise, and
+ * `NoRoom` when the output buffer has no space for any bytes this time (the client asks again in a new request).
+ *
+ * Fails with `MAPI_E_TOO_BIG` when a stream that had to be rebuilt is too large, and with `MAPI_E_CALL_FAILED` when
+ * the stream was lost part-way through (see `loadFastTransferBuffer`) - never with bytes from a different stream.
+ * Failure responses carry only `ReturnValue`, like every other failing handler here. `BackoffTime` is never emitted.
+ *
+ * @author Jean-Philippe Steinmetz
+ */
+export declare class RopFastTransferSourceGetBufferHandler implements RopHandler {
+    readonly ropId = 78;
+    handle(reader: BufferReader, writer: BufferWriter, context: RopContext): Promise<void>;
+}

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

@@ -0,0 +1,25 @@
+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.
+ *
+ * The table holds no rows. It records which kind of item the folder contains (`contentsKind`, decided once here
+ * from the folder's own `type`: Calendar folders list `"calendarEvent:<uid>"` rows, Contacts `"contact:<uid>"`,
+ * Tasks `"task:<uid>"`, everything else `"message:<uid>"`), and `RopQueryRows` reads each requested window from
+ * the database - see `ContentsTable.ts`.
+ *
+ * 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.
+ *
+ * @author Jean-Philippe Steinmetz
+ */
+export declare class RopGetContentsTableHandler implements RopHandler {
+    readonly ropId = 5;
+    readonly responseHandleIndexOffset = 3;
+    handle(reader: BufferReader, writer: BufferWriter, context: RopContext): Promise<void>;
+}

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

@@ -0,0 +1,18 @@
+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;
+    readonly responseHandleIndexOffset = 3;
+    handle(reader: BufferReader, writer: BufferWriter, context: RopContext): Promise<void>;
+}

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

@@ -0,0 +1,26 @@
+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. That includes
+ * a client-requested `propertyType` that doesn't match what a tag's own `propertyId` actually resolves to
+ * (`PropertyResolvers.writePropertyValueSafely`, shared with `RopQueryRowsHandler`) - not just a `propertyId`
+ * this codebase has no data for.
+ *
+ * `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,106 @@
+import type { RepoUtils } from "@rapidrest/service-core";
+import type { AuditLogParams, 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";
+import type { ExecuteBudget } from "./ExecuteBudget.js";
+import { type HandleDataStore } from "./HandleDataCache.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;
+    /** Records an audit log entry as the calling user, the same way the REST routes do. Optional like the repos
+     * above: absent when the route has no audit log class configured, in which case nothing is recorded. */
+    audit?: (params: AuditLogParams) => Promise<void>;
+    /** Recomputes, re-caches and publishes the given folders' `unreadCount`/`totalCount` - restapi's
+     * `refreshFolderCounts()` (`@rapidmx/restapi`), bound to this route's own `messageRepo`/`folderRepo`/`folderClass`/
+     * `notificationUtils`. `Folder.unreadCount`/`totalCount` are a cache restapi's own writes keep fresh (see
+     * `FolderCountUtils.ts`'s module doc comment); a handler that adds, deletes or moves a `Message` row through
+     * `context.messageRepo` itself - never through a `BaseFolderRoute`/`BaseMessageRoute` this library already refreshes
+     * after - must call this for every folder it touched, or Outlook's own folder pane (which reads
+     * `PidTagContentCount`/`PidTagContentUnreadCount` straight off the stored fields, not derived on read - see
+     * `PropertyResolvers.ts`/`FolderTarget.ts`) goes stale. `bumpSyncKey` should be `true` when a message was added to a
+     * folder (restapi's own convention - see `refreshFolderCounts()`'s doc comment), and left unset for a plain
+     * deletion or status change. Always present in real use (`BaseMapiEmsmdbRoute.dispatch()` populates it
+     * unconditionally); optional here only so existing `RopContext`-literal test fixtures that predate this need no
+     * new field, the same reasoning `contactRepo`/`taskRepo`/`labelRepo` above already documents. */
+    notifyFolderCounts?: (folderUids: Iterable<string | undefined | null>, options?: {
+        bumpSyncKey?: boolean;
+    }) => Promise<void>;
+    /** Shared storage for FastTransfer streams and write-stream chunks. Absent in unit tests, where
+     * `defaultHandleDataStore` (this process only) is used - see `handleDataStoreOf`. */
+    handleData?: HandleDataStore;
+    /** This request's work budget, set by `dispatchRops`. Absent when a handler runs on its own. */
+    budget?: ExecuteBudget;
+    /** The bytes still free in this request's ROP output buffer for the current ROP's response, set by
+     * `dispatchRops` before each ROP. Handlers returning variable-size data (`RopReadStream`,
+     * `RopFastTransferSourceGetBuffer`, `RopQueryRows`) shrink their response to fit. Absent means unlimited. */
+    ropOutputRemaining?: number;
+}
+/** The `HandleDataStore` a handler should use for `context`. */
+export declare function handleDataStoreOf(context: Pick<RopContext, "handleData">): HandleDataStore;
+/**
+ * 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;
+    /** Where the handle index a failure response echoes sits in the request, counting the `RopId` byte as 0. Most
+     * ROPs echo `InputHandleIndex` (2, the default); ROPs that create an object echo `OutputHandleIndex` (3). Used
+     * by `RopDispatcher` to write a failure response when the handler throws. */
+    readonly responseHandleIndexOffset?: number;
+    /** Zero bytes a failure response carries after `ReturnValue` (`RopReadStream`'s `DataSize`, ...). */
+    readonly failureTailBytes?: number;
+    /** `true` for a ROP that never has a response (`RopRelease`), so a failure writes nothing either. */
+    readonly hasNoResponse?: boolean;
+    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,20 @@
+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;
+    readonly responseHandleIndexOffset = 3;
+    handle(reader: BufferReader, writer: BufferWriter, context: RopContext): void;
+}

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

@@ -0,0 +1,28 @@
+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;
+    readonly responseHandleIndexOffset = 3;
+    handle(reader: BufferReader, writer: BufferWriter, context: RopContext): Promise<void>;
+}

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

@@ -0,0 +1,28 @@
+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;
+    readonly responseHandleIndexOffset = 3;
+    handle(reader: BufferReader, writer: BufferWriter, context: RopContext): Promise<void>;
+}

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

@@ -0,0 +1,43 @@
+import { BufferReader, BufferWriter } from "../codec/BufferCursor.js";
+import type { RopContext, RopHandler } from "./RopHandler.js";
+/** The most rows one `RopQueryRows` returns. Fewer rows than requested is normal table paging: the client asks
+ * again from the new cursor position. */
+export declare const MAX_ROWS_PER_QUERY = 500;
+/**
+ * `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. That "never an error" promise covers a client-requested
+ * `propertyType` that doesn't match what a column's own `propertyId` resolves to, not just an entirely
+ * unmodeled `propertyId` - `buildRow` writes each column through `PropertyResolvers.writePropertyValueSafely`,
+ * which falls back to the same type-appropriate default there too, so one row's mismatched column degrades
+ * instead of failing this whole call (and discarding every row already built in it).
+ *
+ * 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,20 @@
+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. It is
+ * likewise held to the room left in the request's ROP output buffer (`context.ropOutputRemaining`).
+ * 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;
+    readonly failureTailBytes = 2;
+    handle(reader: BufferReader, writer: BufferWriter, context: RopContext): Promise<void>;
+}

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

@@ -0,0 +1,15 @@
+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;
+    readonly hasNoResponse = true;
+    handle(reader: BufferReader, _writer: BufferWriter, context: RopContext): void;
+}

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

@@ -0,0 +1,59 @@
+import { type CalendarEvent } from "@rapidmx/restapi";
+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). Saving never invites anyone: a saved revision is stamped as already handled (`inviteSequenceSent =
+ * sequence`), so restapi's `MeetingSchedulingJob` skips it until `RopSubmitMessageHandler.submitAppointment` asks for
+ * invites. Attendees of a submitted meeting are then mailed by that job, which is why a meeting is capped at
+ * `MAX_RECIPIENTS_PER_MESSAGE` attendees here. Client-supplied times and reminder minutes that don't parse are ignored (the field keeps its
+ * existing or default value) rather than stored as `Invalid Date`/`NaN`, and an update is versioned (`asEntity`).
+ *
+ * @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.
+     *
+     * Returns `undefined`, saving nothing, for more than `MAX_RECIPIENTS_PER_MESSAGE` attendees: restapi's
+     * `MeetingSchedulingJob` mails every attendee of a saved meeting.
+     */
+    private saveAppointment;
+}
+/**
+ * `true` when an update changes what attendees were invited to: the start or end time, location, recurrence, or
+ * who is invited. The same fields restapi's `BaseCalendarEventRoute.update()` bumps `sequence` for (a MAPI save
+ * never sets `status`), so an edit made in Outlook is re-sent to attendees and supersedes their copy (RFC 5546
+ * `SEQUENCE`) exactly like one made through REST.
+ */
+export declare function isSchedulingRelevantChange(existing: Pick<CalendarEvent, "startDate" | "endDate" | "location" | "recurrenceRule" | "attendees">, updated: Pick<CalendarEvent, "startDate" | "endDate" | "location" | "recurrenceRule" | "attendees">): boolean;

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;
+}