@rapidmx/mapi-plugin 1.0.0-beta.10

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

@@ -0,0 +1,145 @@
+/** How long an entry lives without being read - the same idle lifetime as a session. */
+export declare const HANDLE_DATA_TTL_MS: number;
+/** The most bytes this process keeps across all entries before evicting the least recently used ones. */
+export declare const HANDLE_DATA_MAX_BYTES: number;
+/**
+ * A process-local, byte-bounded LRU with TTL for large per-handle data: an opened stream's decoded message body
+ * and a FastTransfer handle's built stream. Keeping these out of the session JSON means an `Execute` doesn't
+ * re-serialize megabytes to Redis, and a `RopReadStream` doesn't re-fetch and re-parse the whole MIME message
+ * for every chunk.
+ *
+ * It is only a cache. Every caller can rebuild an entry from the handle's own (small) session state, so a miss
+ * (another replica served the previous request, eviction, TTL) costs one rebuild, never wrong data. Keys carry
+ * the handle's generation (see `assignHandle`), so a reused handle index never picks up a previous handle's data.
+ */
+export declare class HandleDataCache {
+    private readonly maxBytes;
+    private readonly ttlMs;
+    private readonly entries;
+    private totalBytes;
+    constructor(maxBytes?: number, ttlMs?: number);
+    get(key: string): Buffer | undefined;
+    /** Stores `value` under `key`. A value larger than the whole budget isn't cached at all. */
+    set(key: string, value: Buffer): void;
+    /** The size of the live entry at `key`, without refreshing it or changing its recency. */
+    sizeOf(key: string): number | undefined;
+    delete(key: string): void;
+    /** The bytes currently held, for tests and diagnostics. */
+    get size(): number;
+}
+/** The process-wide instance every handler shares. */
+export declare const handleDataCache: HandleDataCache;
+/** The cache key for the handle at `handleIndex`, as of its current generation. A generation is a random nonce
+ * (see `assignHandle`), so a key is never reused, not even by a request whose session changes were never saved. */
+export declare function handleDataKey(sessionUid: string, handleIndex: number, generation: string | undefined): string;
+/** The `HandleDataStore` key of the write stream at `handleIndex`. */
+export declare function writeStreamKey(sessionUid: string, handleIndex: number, generation: string | undefined): string;
+/** The most bytes of FastTransfer streams and write-stream chunks one session keeps stored at once. */
+export declare const MAX_HANDLE_DATA_BYTES_PER_SESSION: number;
+/** The most bytes of FastTransfer streams and write-stream chunks one user keeps stored at once, across all of their
+ * sessions. */
+export declare const MAX_HANDLE_DATA_BYTES_PER_USER: number;
+/** How long an owner index outlives its last write: a session's longest lifetime. */
+export declare const HANDLE_DATA_INDEX_TTL_SECONDS: number;
+/** The most chunks one write stream keeps. Each `RopWriteStream` stores one chunk, so this bounds the hash a stream
+ * builds up (and the work `readChunks` does) however small the writes are. */
+export declare const MAX_CHUNKS_PER_STREAM = 8192;
+/** How often, at most, an owner index that is over its quota is recounted from its members. Between recounts a write is
+ * checked against the index's running total alone, so a client hammering a full quota can't make every write walk
+ * every member. */
+export declare const OWNER_RECOUNT_INTERVAL_MS = 1000;
+/** An index that stored data is counted against: the keys it holds and the most bytes they may add up to. */
+export interface HandleDataOwner {
+    index: string;
+    maxBytes: number;
+}
+/** The index of everything a session stores, used for its quota and to delete it all when the session ends. */
+export declare function sessionHandleDataIndex(sessionUid: string): string;
+/** The quota owners a write by `sessionUid` (belonging to `userUid`) counts against. */
+export declare function handleDataOwners(sessionUid: string, userUid: string): HandleDataOwner[];
+/**
+ * Where per-handle data that has to outlive one `Execute` lives: a built FastTransfer stream, and the chunks a write
+ * stream has accumulated. With Redis (`RedisHandleDataStore`) every replica sees the same data, so a client can page
+ * a stream out or finish writing a body through any pod. Without it (`MemoryHandleDataStore`) the data is only in
+ * this process.
+ *
+ * **Quotas.** A write given `owners` is recorded in each owner's index and refused (`false`, nothing stored) when it
+ * would take any owner past its `maxBytes`. Sizes are raw (unencoded) bytes. Every write costs O(1) per owner: each
+ * index keeps a running total, and a chunked stream keeps its own size (the end of its furthest chunk), so neither the
+ * stream's chunks nor the index's members are walked. A delete given the same `owners` takes the key's bytes off their
+ * totals. Data that disappears otherwise (TTL, eviction, `deleteOwnedBy` of another index, a delete without owners)
+ * keeps counting until a write that the total would refuse recounts the index from its live members, at most once per
+ * `OWNER_RECOUNT_INTERVAL_MS` per index. Totals only ever over-count, never under-count.
+ */
+export interface HandleDataStore {
+    get(key: string): Promise<Buffer | undefined>;
+    /** Stores `value` at `key`. `false` when an owner's quota refused it. */
+    set(key: string, value: Buffer, ttlSeconds: number, owners?: HandleDataOwner[]): Promise<boolean>;
+    /** Stores `data` as the chunk starting at byte `offset` of the stream at `key`. Writing the same offset again
+     * replaces the chunk, so a retried write never duplicates bytes or charges the quota twice. `false` when an owner's
+     * quota refused it, or the stream already has `MAX_CHUNKS_PER_STREAM` chunks and this is a new one. */
+    putChunk(key: string, offset: number, data: Buffer, ttlSeconds: number, owners?: HandleDataOwner[]): Promise<boolean>;
+    /** The first `size` bytes of the stream at `key`, assembled from its chunks, or `undefined` when a chunk is
+     * missing (expired or evicted) and the stream can't be reassembled exactly. */
+    readChunks(key: string, size: number): Promise<Buffer | undefined>;
+    /** Deletes the value or chunked stream at `key`, taking it off the totals of `owners`. */
+    delete(key: string, owners?: HandleDataOwner[]): Promise<void>;
+    /** Deletes everything recorded in the owner index `index`, and the index itself. */
+    deleteOwnedBy(index: string): Promise<void>;
+}
+/** A `HandleDataStore` in this process only, on a `HandleDataCache` (so it is byte-bounded and can evict). */
+export declare class MemoryHandleDataStore implements HandleDataStore {
+    private readonly cache;
+    private readonly indexes;
+    private readonly streams;
+    constructor(cache?: HandleDataCache);
+    get(key: string): Promise<Buffer | undefined>;
+    set(key: string, value: Buffer, _ttlSeconds: number, owners?: HandleDataOwner[]): Promise<boolean>;
+    putChunk(key: string, offset: number, data: Buffer, _ttlSeconds: number, owners?: HandleDataOwner[]): Promise<boolean>;
+    readChunks(key: string, size: number): Promise<Buffer | undefined>;
+    delete(key: string, owners?: HandleDataOwner[]): Promise<void>;
+    deleteOwnedBy(index: string): Promise<void>;
+    /** `true` while `key` still holds a value or its stream's first chunk (a stream missing that can't be read). */
+    private exists;
+    /** Records `key` at `bytes` in every owner index, unless that would take one past its quota. */
+    private admit;
+    /** `true` when `key` at `bytes` keeps `index` within `maxBytes`, recounting an index that looks full (rate limited). */
+    private fits;
+}
+/** Stores a value within its owners' quotas. KEYS: data key, then each owner index. ARGV: data key prefix, member name,
+ * index ttl, recount interval ms, base64 value, ttl, raw bytes, then each owner's max bytes. Returns 1 stored, 0 refused. */
+export declare const SET_WITH_QUOTA_SCRIPT = "\nlocal function recount(index, prefix, indexTtl)\n  local total = 0\n  local members = redis.call('ZRANGE', index, 0, -1, 'WITHSCORES')\n  for j = 1, #members, 2 do\n    if redis.call('EXISTS', prefix .. members[j]) == 0 then\n      redis.call('ZREM', index, members[j])\n    else\n      total = total + tonumber(members[j + 1])\n    end\n  end\n  redis.call('SET', index .. '.total', tostring(total), 'EX', indexTtl)\n  return total\nend\nlocal function admits(index, member, bytes, maxBytes, prefix, recountMs, indexTtl)\n  local stored = redis.call('GET', index .. '.total')\n  local fresh = not stored\n  local total = stored and tonumber(stored) or recount(index, prefix, indexTtl)\n  local old = tonumber(redis.call('ZSCORE', index, member) or 0)\n  if total - old + bytes <= maxBytes then return true end\n  if fresh or not redis.call('SET', index .. '.recount', '1', 'PX', recountMs, 'NX') then return false end\n  total = recount(index, prefix, indexTtl)\n  old = tonumber(redis.call('ZSCORE', index, member) or 0)\n  return total - old + bytes <= maxBytes\nend\nlocal function record(index, member, bytes, indexTtl)\n  local old = tonumber(redis.call('ZSCORE', index, member) or 0)\n  redis.call('ZADD', index, tostring(bytes), member)\n  redis.call('INCRBY', index .. '.total', tostring(bytes - old))\n  redis.call('EXPIRE', index, indexTtl)\n  redis.call('EXPIRE', index .. '.total', indexTtl)\nend\n\nlocal bytes = tonumber(ARGV[7])\nfor i = 2, #KEYS do\n  if not admits(KEYS[i], ARGV[2], bytes, tonumber(ARGV[i + 6]), ARGV[1], ARGV[4], ARGV[3]) then return 0 end\nend\nredis.call('SETEX', KEYS[1], ARGV[6], ARGV[5])\nfor i = 2, #KEYS do record(KEYS[i], ARGV[2], bytes, ARGV[3]) end\nreturn 1\n";
+/** Stores one write-stream chunk within its owners' quotas, in O(1): the hash keeps its size (the end of its furthest
+ * chunk) in the `size` field, and that size is what the owners are charged, so a chunk rewritten at the same offset
+ * isn't charged twice. KEYS: hash key, then each owner index. ARGV: data key prefix, member name, index ttl, recount
+ * interval ms, unpadded base64url chunk, ttl, raw chunk bytes, hash field (offset), max chunks, then each owner's max
+ * bytes. Returns 1 stored, 0 refused (quota, or a new chunk past the max chunks). */
+export declare const PUT_CHUNK_WITH_QUOTA_SCRIPT = "\nlocal function recount(index, prefix, indexTtl)\n  local total = 0\n  local members = redis.call('ZRANGE', index, 0, -1, 'WITHSCORES')\n  for j = 1, #members, 2 do\n    if redis.call('EXISTS', prefix .. members[j]) == 0 then\n      redis.call('ZREM', index, members[j])\n    else\n      total = total + tonumber(members[j + 1])\n    end\n  end\n  redis.call('SET', index .. '.total', tostring(total), 'EX', indexTtl)\n  return total\nend\nlocal function admits(index, member, bytes, maxBytes, prefix, recountMs, indexTtl)\n  local stored = redis.call('GET', index .. '.total')\n  local fresh = not stored\n  local total = stored and tonumber(stored) or recount(index, prefix, indexTtl)\n  local old = tonumber(redis.call('ZSCORE', index, member) or 0)\n  if total - old + bytes <= maxBytes then return true end\n  if fresh or not redis.call('SET', index .. '.recount', '1', 'PX', recountMs, 'NX') then return false end\n  total = recount(index, prefix, indexTtl)\n  old = tonumber(redis.call('ZSCORE', index, member) or 0)\n  return total - old + bytes <= maxBytes\nend\nlocal function record(index, member, bytes, indexTtl)\n  local old = tonumber(redis.call('ZSCORE', index, member) or 0)\n  redis.call('ZADD', index, tostring(bytes), member)\n  redis.call('INCRBY', index .. '.total', tostring(bytes - old))\n  redis.call('EXPIRE', index, indexTtl)\n  redis.call('EXPIRE', index .. '.total', indexTtl)\nend\n\nlocal field = ARGV[8]\nif redis.call('HEXISTS', KEYS[1], field) == 0 and redis.call('HLEN', KEYS[1]) > tonumber(ARGV[9]) then return 0 end\nlocal size = math.max(tonumber(redis.call('HGET', KEYS[1], 'size') or 0), tonumber(field) + tonumber(ARGV[7]))\nfor i = 2, #KEYS do\n  if not admits(KEYS[i], ARGV[2], size, tonumber(ARGV[i + 8]), ARGV[1], ARGV[4], ARGV[3]) then return 0 end\nend\nredis.call('HSET', KEYS[1], field, ARGV[5], 'size', tostring(size))\nredis.call('EXPIRE', KEYS[1], ARGV[6])\nfor i = 2, #KEYS do record(KEYS[i], ARGV[2], size, ARGV[3]) end\nreturn 1\n";
+/** Deletes one data key and takes it off its owners' totals. KEYS: data key, then each owner index. ARGV: member name. */
+export declare const DELETE_WITH_OWNERS_SCRIPT = "\nredis.call('DEL', KEYS[1])\nfor i = 2, #KEYS do\n  local old = redis.call('ZSCORE', KEYS[i], ARGV[1])\n  if old then\n    redis.call('ZREM', KEYS[i], ARGV[1])\n    if redis.call('EXISTS', KEYS[i] .. '.total') == 1 then redis.call('INCRBY', KEYS[i] .. '.total', tostring(-tonumber(old))) end\n  end\nend\nreturn 1\n";
+/** Deletes every key an owner index names, then the index with its total and recount marker. KEYS: index. ARGV: data key
+ * prefix. Returns the members (unprefixed keys) it deleted, so the caller can drop its local copies too. */
+export declare const DELETE_OWNED_SCRIPT = "\nlocal members = redis.call('ZRANGE', KEYS[1], 0, -1)\nfor _, member in ipairs(members) do\n  redis.call('DEL', ARGV[1] .. member)\nend\nredis.call('DEL', KEYS[1], KEYS[1] .. '.total', KEYS[1] .. '.recount')\nreturn members\n";
+/** The prefix of every handle data key in Redis. */
+export declare const HANDLE_DATA_PREFIX = "mapi.handle.";
+/**
+ * A `HandleDataStore` on a node-redis client, with this process's `HandleDataCache` in front for reads. Values are
+ * stored base64-encoded (a plain string works with any client configuration); a write stream is a hash of
+ * `offset -> chunk` plus its `size`. Owner indexes are sorted sets (`mapi.handle-owner.<index>`) of key -> raw bytes, with
+ * a running total beside each (see `OWNER_INDEX_LUA`).
+ */
+export declare class RedisHandleDataStore implements HandleDataStore {
+    private readonly client;
+    private readonly local;
+    constructor(client: any, local?: HandleDataCache);
+    get(key: string): Promise<Buffer | undefined>;
+    set(key: string, value: Buffer, ttlSeconds: number, owners?: HandleDataOwner[]): Promise<boolean>;
+    putChunk(key: string, offset: number, data: Buffer, ttlSeconds: number, owners?: HandleDataOwner[]): Promise<boolean>;
+    readChunks(key: string, size: number): Promise<Buffer | undefined>;
+    delete(key: string, owners?: HandleDataOwner[]): Promise<void>;
+    deleteOwnedBy(index: string): Promise<void>;
+}
+/** The Redis key of an owner index. */
+export declare function ownerKey(index: string): string;
+/** The store used when a `RopContext` doesn't carry one (unit tests, or a route built without a session manager). */
+export declare const defaultHandleDataStore: HandleDataStore;

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

@@ -0,0 +1,30 @@
+import type { RopContext } from "./RopHandler.js";
+/**
+ * Handles a submitted `"IPM.Schedule.Meeting.Resp.{Pos,Neg,Tent}"` message - an attendee's own response to a
+ * meeting invite. Delegated to from `RopSubmitMessageHandler` for that message-class prefix, instead of the ordinary
+ * mail or Appointment paths. Returns the ROP's `ReturnValue`.
+ *
+ * Mirrors restapi's `BaseCalendarEventRoute.respond()`. It correlates the response via `PidLidGlobalObjectId`
+ * (echoed by a real client from the invite it's responding to - see `GlobalObjectId.ts`) to **the caller's own
+ * copy** of the meeting: the query is scoped to the caller's `mailboxUid`, which is the access check. The
+ * organizer's copy (in another mailbox) is never touched here; the organizer's server applies the iTIP `REPLY` sent
+ * below, exactly as for a REST response. A native Outlook `GlobalObjectId` decodes to the uppercase hex form of its
+ * iCalendar UID, which is matched in either case.
+ *
+ * **One occurrence of a recurring meeting** (the `GlobalObjectId`'s instance date is set): the caller's exception
+ * copy for that date is used when there is one, comparing dates in the event's own time zone. Without one, the
+ * series is left alone - responding to one occurrence must not change or delete every other occurrence. Declining
+ * adds the occurrence to the caller's series `recurrenceRule.exceptions` (so it leaves their calendar); accepting or
+ * tentatively accepting changes nothing locally. Either way the `REPLY` names just that occurrence (`RECURRENCE-ID`).
+ *
+ * **The whole meeting** (no instance date, or a copy that doesn't recur): the caller's `Attendee.responseStatus` is
+ * recorded; declining soft-deletes the caller's copy instead. Declining an occurrence through its exception copy also
+ * adds that occurrence to the series' exceptions, so the series doesn't show it again. Every update is versioned
+ * (`asEntity`), so a concurrent change fails the response instead of being overwritten.
+ *
+ * The `REPLY` (restapi's own `buildEventIcs`) goes out through `sendOrThrow`, so a transport that rejects it is
+ * reported as `MAPI_E_CALL_FAILED` instead of success; the response itself stays recorded. An organizer or attendee
+ * address that isn't a plain SMTP address is not mailed at all. A response that can't be matched to a meeting the
+ * caller attends is an error (`MAPI_E_NOT_FOUND`/`MAPI_E_INVALID_PARAMETER`), not a silent success.
+ */
+export declare function submitMeetingResponse(messageClass: string, draftProperties: Record<string, string>, context: RopContext): Promise<number>;

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

@@ -0,0 +1,35 @@
+import type { RepoUtils } from "@rapidrest/service-core";
+import { type BlobStore } from "@rapidmx/restapi";
+import type { MapiObjectHandle } from "../MapiSessionManager.js";
+import type { ExecuteBudget } from "./ExecuteBudget.js";
+import type { RopContext } from "./RopHandler.js";
+/** `PidTagBody` (`[MS-OXPROPS]`): property ID `0x1000`, `PtypString`. The only streamable property this
+ * pragmatic subset supports via `RopOpenStream`/`RopReadStream` - `PidTagHtml`/`PidTagRtfCompressed` are a
+ * documented gap (see `RopOpenStreamHandler`'s own doc comment). */
+export declare const PID_TAG_BODY = 4096;
+/**
+ * Resolves a `"message:<uid>"` target's plain-text body as the exact byte sequence `RopReadStream` must serve
+ * for a streamed `PtypString` property - confirmed via `[MS-OXCPRPT]`'s `RopOpenStream` page ("a string of
+ * Unicode characters in UTF-16LE format encoding with terminating null character"), the identical encoding
+ * `writePropertyValue()` already uses for an inline `PtypString` value, so this reuses
+ * `BufferWriter.writeNullTerminatedUtf16LE` rather than reimplementing it.
+ *
+ * Always derived from the message's raw MIME source (`bodyBlobKey`, via `mailparser` - the same fallback path
+ * `ItemOperationsCommand.fetchMessage()` already uses for EAS's own plain-text body delivery) rather than
+ * `sanitizedHtmlBlobKey` - `PidTagBody` is specifically the plain-text body per `[MS-OXPROPS]`, unlike EAS's
+ * `Body` element, which can carry either format tagged by its own `Type` field.
+ *
+ * Does no caching itself - `loadStreamBody` below is what the stream ROPs call. With a `budget`, nothing is fetched
+ * once its bytes are used up, and the raw message's size is charged before it is parsed.
+ */
+export declare function resolveMessageBodyBytes(target: string, messageRepo: RepoUtils<any>, blobStore: BlobStore, budget?: ExecuteBudget): Promise<Buffer>;
+/**
+ * The body bytes for the read stream at `handleIndex`. Parsed once and kept in `HandleDataCache` (outside the
+ * session JSON) for the life of the handle, so reading a large body in many `RopReadStream` chunks costs one
+ * fetch and one MIME parse instead of one per chunk. A cache miss (eviction, or a request served by another
+ * replica) just resolves the body again: a stored message's body never changes, so the bytes are the same.
+ *
+ * Within one `Execute`, streams opened on the same message share a single parse (`ExecuteBudget.bodies`), and each
+ * parse's bytes count against the request's byte budget.
+ */
+export declare function loadStreamBody(context: RopContext, handleIndex: number, stream: MapiObjectHandle): Promise<Buffer>;

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

@@ -0,0 +1,45 @@
+import type { RepoUtils } from "@rapidrest/service-core";
+import type { MapiSessionContext } from "../MapiSessionManager.js";
+import type { ExecuteBudget } from "./ExecuteBudget.js";
+import { type RepoSort } from "./RepoPaging.js";
+/**
+ * The `RopGetContentsTable` analog of `FolderTarget.ts`: resolves a `"message:<uid>"` row target (see
+ * `RopGetContentsTableHandler`'s own doc comment for why contents-table rows use this prefix instead of
+ * `FolderTarget.ts`'s `"folder:"`/`"virtual:"`) into the display data a message-table row needs.
+ */
+export interface MessageTargetInfo {
+    subject: string;
+    read: boolean;
+    hasAttachments: boolean;
+    receivedDate: Date;
+    /** `Label.uid`s applied to this message (Gmail-style, independent of folder placement) - resolved to
+     * display names for `PidNameKeywords` (Outlook Categories) by `PropertyResolvers.ts`, which is where the
+     * `labelRepo` needed to translate a uid into a name lives. */
+    labelUids: string[];
+}
+/** Degrades to empty-looking values for a `"message:<uid>"` target whose real `Message` has since vanished
+ * (soft-deleted or otherwise), the same "don't fail the whole ROP over one stale row" principle
+ * `FolderTarget.resolveFolderInfo` already applies. */
+export declare function resolveMessageInfo(target: string, messageRepo: RepoUtils<any>): Promise<MessageTargetInfo>;
+/** The order a folder's messages are listed in: newest first, ties broken by `uid` so paging is stable. */
+export declare const MESSAGE_SORT: RepoSort;
+/** Resolves the messages directly in `folderUid`, newest first and capped at `MAX_COLLECTION_ROWS`, as
+ * `"message:<uid>"` target strings. */
+export declare function resolveFolderMessages(folderUid: string, messageRepo: RepoUtils<any>, budget?: ExecuteBudget): Promise<string[]>;
+/**
+ * Returns `target`'s existing MID if an earlier `RopQueryRows` row already assigned one, otherwise assigns and
+ * remembers the next free small integer MID. The exact `FolderTarget.assignOrGetFid` pattern, adapted for
+ * messages: this is what lets a client `RopOpenMessage` a message it only ever learned about via a
+ * `RopQueryRows` row's `PidTagMid` column.
+ *
+ * Backed by `session.messageTargetIds` (target -> MID) and `session.nextMessageId`, an O(1) reverse index/
+ * counter pair rather than a linear scan of `session.messageIds` plus a `Math.max(...spread)` over its keys -
+ * see `FolderTarget.assignOrGetFid`'s own doc comment for why both of those were real costs (not just
+ * theoretical ones) at real mailbox/session scale: `messageIds` only ever grows for a session's lifetime as a
+ * client pages through a mailbox, so a linear-scan lookup repeated once per row is quadratic over a session
+ * that pages through many messages.
+ */
+export declare function assignOrGetMid(session: MapiSessionContext, target: string): number;
+/** The most MIDs one session keeps mapped. A session paging through a very large mailbox would otherwise grow its
+ * MID maps - saved with the session on every `Execute` - without bound. */
+export declare const MAX_MESSAGE_IDS = 20000;

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

@@ -0,0 +1,50 @@
+import type { MapiSessionContext } from "../MapiSessionManager.js";
+/** A `PropertyName` (`[MS-OXCDATA]` §2.6.1): identifies a named property by a property-set `guid` plus either a
+ * numeric `lid` (`kind: "lid"`) or a string `name` (`kind: "name"`) - never both. `guid` is the textual form
+ * `MapiGuid.ts`'s `encodeGuid`/`decodeGuid` already produce/consume (the wire `PropertyName` structure's own
+ * `GUID` field is a `FlatUID` - confirmed, per its own spec page, to be byte-identical to the same little-endian
+ * `Data1`/`Data2`/`Data3`+as-is-`Data4` layout `MapiGuid.ts` already implements, so no second GUID codec is
+ * needed here). */
+export interface PropertyName {
+    guid: string;
+    kind: "lid" | "name";
+    lid?: number;
+    name?: string;
+}
+/** The most distinct named properties one session registers. The registry is saved with the session on every
+ * `Execute`, and a name can be up to 255 bytes, so letting a client fill the whole `0x8000`-`0xFFFF` ID space
+ * would make every request carry megabytes of session state. Real clients register a few hundred at most. */
+export declare const MAX_NAMED_PROPERTIES_PER_SESSION = 4096;
+/**
+ * Returns `propertyName`'s existing numeric property ID if an earlier `RopGetPropertyIdsFromNames` call in
+ * this session already assigned one, otherwise assigns and remembers the next free ID starting at
+ * `FIRST_NAMED_PROPERTY_ID`. This pragmatic subset always behaves as if the request's own `Flags` field
+ * requested "assign a new ID if unmapped" (`0x02`) - real Exchange's alternative (`0x00`, "only return
+ * already-mapped IDs") exists to let a client probe without committing a mailbox-wide registration; since this
+ * registry is already only ever session-scoped (not a real persisted per-mailbox mapping table), there is no
+ * meaningful difference between "probe" and "assign" here.
+ *
+ * Backed by `session.namedProperties`/`namedPropertyIds` (a forward and reverse map, kept in sync) and
+ * `session.nextNamedPropertyId`, an O(1) lookup/assignment pair rather than a linear scan plus a
+ * `Math.max(...spread)` over `Object.values(session.namedProperties)` - both real costs at scale: the spread
+ * form risks a `RangeError: Maximum call stack size exceeded` once a session has registered enough distinct
+ * names to exceed V8's function-argument-count limit, and the registry only ever grows for a session's
+ * lifetime, so a linear scan repeated once per property per row is quadratic over a session that resolves many
+ * named properties.
+ *
+ * Once `nextNamedPropertyId` would exceed `LAST_NAMED_PROPERTY_ID` (`MAX_NAMED_PROPERTIES_PER_SESSION` distinct
+ * names already registered this session), a *new*
+ * name can no longer be assigned a real ID; this returns `0x0000` for it instead of throwing, the exact value
+ * `[MS-OXCPRPT]`'s own `RopGetPropertyIdsFromNames` processing rules already use for "this `PropertyName`
+ * could not be resolved" (the same value this pragmatic subset already produces for a `Kind = 0xFF` entry) -
+ * not a new failure mode, just the same one applied to a different unmappable case. A name already registered
+ * before the registry filled up keeps returning its real, previously-assigned ID.
+ */
+export declare function assignOrGetNamedPropertyId(session: MapiSessionContext, propertyName: PropertyName): number;
+/** The reverse lookup `RopSetProperties`/`RopGetPropertiesSpecific`/`RopQueryRows` use to recognize an incoming
+ * property ID `>= 0x8000` as one of this session's own mapped named properties - an O(1) lookup against
+ * `session.namedPropertyIds` (kept in sync by `assignOrGetNamedPropertyId`) rather than a linear scan of
+ * `session.namedProperties` with a `JSON.parse` per candidate - see that function's own doc comment for why
+ * this matters at scale, particularly since this is called once per named-property column per row from
+ * `RopQueryRows`. */
+export declare function resolveNamedProperty(session: MapiSessionContext, propertyId: number): PropertyName | undefined;

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

@@ -0,0 +1,86 @@
+import { BufferWriter } from "../codec/BufferCursor.js";
+import { PropertyType, PropertyValueData } from "../codec/PropertyValue.js";
+import type { MapiSessionContext } from "../MapiSessionManager.js";
+import { CalendarEventTargetInfo } from "./CalendarEventTarget.js";
+import { ContactTargetInfo } from "./ContactTarget.js";
+import { FolderResolutionCache, FolderTargetInfo } from "./FolderTarget.js";
+import { MessageTargetInfo } from "./MessageTarget.js";
+import type { RopContext } from "./RopHandler.js";
+import { TaskTargetInfo } from "./TaskTarget.js";
+/** A type-appropriate zero/empty value for a requested property this handler has no real data for - keeps
+ * `StandardPropertyRow` encoding valid (a real value of the right type, per `writePropertyValue`'s
+ * expectations) without needing to model every property a client could ever ask for. Shared by
+ * `RopQueryRowsHandler` (table rows) and `RopGetPropertiesSpecificHandler` (single-object property fetch). */
+export declare function defaultValueForType(propertyType: PropertyType): PropertyValueData;
+/**
+ * Encodes `value` as `propertyType` into `writer`, falling back to `defaultValueForType(propertyType)`'s own
+ * value if that throws - `RopQueryRowsHandler`/`RopGetPropertiesSpecificHandler`'s "an unsupported property
+ * falls back to a type-appropriate default, never an error" contract (see their own doc comments) was only true
+ * for a `propertyId` this codebase has no data for; it wasn't actually true for a `propertyId` it resolves fine
+ * whose value just doesn't fit the *client's own requested* `propertyType` for that column (`SetColumns` never
+ * cross-checks a column's declared type against what its resolver actually returns) - e.g. `PidTagSubject`'s
+ * plain string against a client-requested `PtypGuid` column throws inside `encodeGuid()`, well downstream of the
+ * `xxxValueFor` switch that only ever looks at `propertyId`. That escaped all the way to `RopDispatcher` and
+ * failed the *whole* ROP (discarding every row `RopQueryRows` had already built in that call) instead of just
+ * this one column degrading, the same as an actually-unmodeled property already does.
+ *
+ * Writes into a scratch `BufferWriter` first and only copies its bytes into `writer` once a whole value's worth
+ * encoded cleanly - several `PropertyType` cases (`PtypBinary`, every `PtypMultiple*`) write more than one field
+ * per value, and a value of the wrong *shape* (not just the wrong type) can throw partway through one of those,
+ * which would otherwise leave stray, wrongly-sized bytes in `writer` ahead of every column/row that follows -
+ * silent wire-format corruption worse than the original failure.
+ *
+ * `defaultValueForType(propertyType)` is built to match `writePropertyValue`'s own cases exactly, so the
+ * fallback only fails too when `propertyType` is a value neither function's `switch` recognizes at all (there's
+ * no way to encode a wire type this codec doesn't implement, and `RopSetColumns` never validates `propertyType`
+ * against the known enum) - that still throws, exactly as it already did before this function existed, since a
+ * genuinely unknown type isn't the "known type, mismatched value" case this exists to fix.
+ */
+export declare function writePropertyValueSafely(writer: BufferWriter, propertyType: PropertyType, value: PropertyValueData): void;
+/** Resolves one requested property's value for a `"folder:<uid>"`/`"virtual:<name>"` target. */
+export declare function folderValueFor(session: MapiSessionContext, propertyId: number, propertyType: PropertyType, target: string, info: FolderTargetInfo): PropertyValueData;
+/** Resolves one requested property's value for a `"message:<uid>"` target. `labelNames` is this message's own
+ * `labelUids` already resolved to display names (see `resolvePropertyValues`'s own doc comment) - a plain
+ * parameter rather than a repo lookup here, since this function (like every other `xxxValueFor`) is
+ * synchronous and can't do its own async DB access. */
+export declare function messageValueFor(session: MapiSessionContext, propertyId: number, propertyType: PropertyType, target: string, info: MessageTargetInfo, labelNames?: string[]): PropertyValueData;
+/** Resolves one requested property's value for a `"calendarEvent:<uid>"` target. Almost every Appointment
+ * property is a *named* property (`PidLid*`, no fixed numeric ID) rather than a plain `PidTag*` - a property ID
+ * `>= 0x8000` is resolved back to its `(PropertySet GUID, LID)` identity via `resolveNamedProperty` before this
+ * can dispatch on it (see `NamedPropertyRegistry.ts`'s own doc comment and the architecture plan's "Calendar
+ * support" section for the full named-property table this switch implements). */
+export declare function calendarEventValueFor(session: MapiSessionContext, propertyId: number, propertyType: PropertyType, target: string, info: CalendarEventTargetInfo, callerAddress: string): PropertyValueData;
+/** Resolves one requested property's value for a `"contact:<uid>"` target - a `Folder` of type `CONTACTS`'s
+ * content-table rows/opened items. Every field here is a plain fixed `PidTag` (`[MS-OXOCNTC]`), unlike Calendar/
+ * Task's named-property tables, since Contact's own well-known fields all have real numeric IDs. */
+export declare function contactValueFor(session: MapiSessionContext, propertyId: number, propertyType: PropertyType, target: string, info: ContactTargetInfo): PropertyValueData;
+/** Resolves one requested property's value for a `"task:<uid>"` target - a `Folder` of type `TASKS`'s
+ * content-table rows/opened items. Almost every Task-specific property is a *named* property (`PidLid*`) under
+ * `PSETID_Task`, resolved back to its `(PropertySet GUID, LID)` identity via `resolveNamedProperty` exactly the
+ * same way `calendarEventValueFor` handles `PSETID_Appointment`/`PSETID_Common` - see `TaskNamedProperties.ts`'s
+ * own doc comment for the LID table this switch implements. */
+export declare function taskValueFor(session: MapiSessionContext, propertyId: number, propertyType: PropertyType, target: string, info: TaskTargetInfo): PropertyValueData;
+/** An optional, purely request-scoped (never persisted) memo shared across every `resolvePropertyValues` call
+ * within one ROP handler invocation - e.g. one `RopQueryRows` call resolving many table rows, or the (rarer)
+ * case of `RopGetPropertiesSpecific` resolving many columns for one object. Without it, both `allFolders` (via
+ * `resolveFolderInfo`'s own `hasChildren` computation) and `callerAddress` (the calendar organizer/attendee
+ * lookup below) would be re-fetched from the repo on every single row even though they can only ever have one
+ * value for the whole batch (this mailbox's folder list, this mailbox's own primary address) - a real,
+ * measurable cost for a hierarchy/calendar table with many rows, not just a theoretical one. A caller that
+ * resolves only a single target (`RopGetPropertiesSpecificHandler`) can simply omit this - resolving without a
+ * cache is still correct, just not deduplicated across calls it doesn't make anyway. */
+export interface ResolutionCache extends FolderResolutionCache {
+    callerAddress?: string;
+    /** `Label.uid` -> `Label.name`, for the whole mailbox - built at most once per call the same way
+     * `allFolders`/`callerAddress` are, the first time a message row actually has a non-empty `labelUids` to
+     * resolve (most messages have none, so this stays unbuilt for a page with no labeled messages at all). */
+    labelNamesByUid?: Map<string, string>;
+}
+/** Resolves every column in `columns` for a single `target` (a `"folder:"`/`"virtual:"`/`"message:"`/
+ * `"calendarEvent:"`/`"contact:"`/`"task:"` target string), in order - the shared implementation behind both
+ * `RopQueryRowsHandler` (one call per table row) and `RopGetPropertiesSpecificHandler` (one call for the single
+ * object a handle refers to). */
+export declare function resolvePropertyValues(target: string, columns: {
+    propertyId: number;
+    propertyType: PropertyType;
+}[], context: Pick<RopContext, "mailboxUid" | "session" | "folderRepo" | "messageRepo" | "calendarEventRepo" | "mailboxRepo" | "contactRepo" | "taskRepo" | "labelRepo" | "budget">, cache?: ResolutionCache): Promise<PropertyValueData[]>;

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

@@ -0,0 +1,30 @@
+import type { RepoUtils } from "@rapidrest/service-core";
+import type { ExecuteBudget } from "./ExecuteBudget.js";
+/** `RepoUtils.find()`'s own largest page. */
+export declare const REPO_PAGE_SIZE = 1000;
+/** The most rows gathered by `findAllCapped`. */
+export declare const MAX_COLLECTION_ROWS = 10000;
+/** A sort order in `RepoUtils` query syntax, e.g. `{ receivedDate: "DESC", uid: "ASC" }`. Always end with a
+ * unique field so pages don't overlap or skip rows that tie on the leading fields. */
+export type RepoSort = Record<string, "ASC" | "DESC">;
+/**
+ * Fetches one page. `limit`/`page`/`sort` go in both the query (what the SQL query builder reads) and the options
+ * (what Mongo reads); without them each backend silently returns its own 100-row default in an unspecified order.
+ *
+ * With a `budget`, the query is charged before it runs and the rows it returned right after, so a request past its
+ * `ExecuteBudget` stops before the next query.
+ */
+export declare function findPage<T>(repo: RepoUtils<any>, query: Record<string, any>, sort: RepoSort, page: number, pageSize?: number, budget?: ExecuteBudget): Promise<T[]>;
+/**
+ * Fetches every row matching `query`, in `sort` order, up to `cap` rows. `truncated` is `true` when more rows may
+ * exist past the cap.
+ */
+export declare function findAllCapped<T>(repo: RepoUtils<any>, query: Record<string, any>, sort: RepoSort, cap?: number, budget?: ExecuteBudget): Promise<{
+    items: T[];
+    truncated: boolean;
+}>;
+/**
+ * Fetches the rows at positions `[start, start + count)` of `query` in `sort` order, reading only the pages that
+ * window touches.
+ */
+export declare function findWindow<T>(repo: RepoUtils<any>, query: Record<string, any>, sort: RepoSort, start: number, count: number, budget?: ExecuteBudget): Promise<T[]>;

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

@@ -0,0 +1,32 @@
+import { type QueryLiteral, type RepoUtils } from "@rapidrest/service-core";
+/** The longest value `boundIndexedValue()` stores verbatim - restapi's `MAX_INDEXED_VALUE_LENGTH`. */
+export declare const MAX_INDEXED_VALUE_LENGTH = 255;
+/**
+ * restapi's `boundIndexedValue`: `value` unchanged when it's at most `MAX_INDEXED_VALUE_LENGTH` characters, otherwise
+ * `sha256:<64 hex digits>` of its UTF-8 bytes. restapi stores `CalendarEvent.icalUid` (and `Message.messageId`/
+ * `conversationId`) this way, so a lookup by one of those identifiers has to bound its value the same way to match.
+ */
+export declare function boundIndexedValue<T extends string | null | undefined>(value: T): T;
+/**
+ * restapi's `asEntity`: `row` as an instance of `repo`'s model class. Before service-core 2.1.0, `RepoUtils.update()`
+ * only enforced its optimistic lock when `existing instanceof BaseEntity`, and the Mongo backend's `find()`/`findOne()`
+ * return plain documents, so passing one straight through turned a versioned update into an unconditional overwrite.
+ * 2.1.0 also locks plain documents carrying a numeric `version`, so this is now defence in depth, kept while restapi
+ * keeps its own copy. SQL rows are already instances and pass through as they are.
+ */
+export declare function asEntity<T>(repo: RepoUtils<any>, row: T): T;
+/**
+ * A `RepoUtils` query value that always matches `value` literally: service-core's `ModelUtils.literal()`, so a
+ * client- or sender-supplied value like `ne(x)` is never read as an operator and `me`/`null`/numeric strings are not
+ * substituted or coerced. Callers still compare the returned rows' field against `value` themselves.
+ */
+export declare function literalQueryValue(value: string): QueryLiteral;
+/**
+ * restapi `MeetingSchedulingJob`'s eligibility rule (`jobs/MeetingSchedulingJob.ts`, `processInviteCandidates`): `true`
+ * while the job will still send invites for `event`'s current revision, i.e. its `inviteSequenceSent` is unset or
+ * differs from its `sequence`. Keep in sync with that job.
+ */
+export declare function isInvitePending(event: {
+    sequence?: number;
+    inviteSequenceSent?: number | null;
+}): boolean;

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

@@ -0,0 +1,24 @@
+import type { BufferReader, BufferWriter } from "../codec/BufferCursor.js";
+import type { RopContext, RopHandler } from "./RopHandler.js";
+/**
+ * `RopCreateMessage` (`[MS-OXCMSG]`/`[MS-OXCROPS]`): begins composing a new message in a folder, producing a
+ * new `"message"` Server object handle later ROPs (`RopSetProperties`, `RopOpenStream`, `RopSaveChangesMessage`)
+ * reference by `InputHandleIndex`. Unlike `RopOpenMessage`'s handle (an already-real, already-saved message),
+ * this handle's `entityUid` is deliberately left `""` - there is no real backing `Message` row, and won't be
+ * one until `RopSubmitMessage` actually sends it (this pragmatic subset has no separate Drafts-folder
+ * persistence step; see `RopSaveChangesMessageHandler`'s own doc comment). `draftFolderUid` remembers the
+ * target folder for that eventual send, and `draftProperties` starts empty, filled in by later
+ * `RopSetProperties`/`RopWriteStream` calls.
+ *
+ * `CodePageId` is decoded to advance past it correctly but not otherwise acted on (this pragmatic subset always
+ * encodes strings as UTF-16LE/UTF-8 directly, the same treatment `RopOpenMessageHandler` gives it).
+ * `AssociatedFlag` (FAI messages - hidden configuration/rules objects, not real mail) is decoded but not
+ * honored - this pragmatic subset's compose/send path only ever produces ordinary mail messages.
+ *
+ * @author Jean-Philippe Steinmetz
+ */
+export declare class RopCreateMessageHandler implements RopHandler {
+    readonly ropId = 6;
+    readonly responseHandleIndexOffset = 3;
+    handle(reader: BufferReader, writer: BufferWriter, context: RopContext): void;
+}

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

@@ -0,0 +1,53 @@
+import type { BufferReader, BufferWriter } from "../codec/BufferCursor.js";
+import type { RopContext, RopHandler } from "./RopHandler.js";
+/** The deepest subfolder nesting a recursive delete walks. */
+export declare const MAX_FOLDER_DEPTH = 32;
+/** The most folders one recursive delete removes. */
+export declare const MAX_FOLDERS_PER_DELETE = 1000;
+/** The most items (messages, events, contacts, tasks) one `RopDeleteFolder` deletes. Past this the ROP stops,
+ * reports `PartialCompletion`, and leaves the folders that still hold items in place; the client can retry. */
+export declare const MAX_ITEMS_PER_DELETE = 10000;
+/**
+ * `RopDeleteFolder` (`[MS-OXCFOLD]`/`[MS-OXCROPS]`, RopId `0x1D`): deletes a folder by `FolderId`, via
+ * `RecoverableRepoUtils.delete()` - see `RopDeleteMessagesHandler.ts`'s own doc comment for why that matters (EAS's
+ * watermark-based incremental delete detection depends on it).
+ *
+ * **Real spec semantics honored**: `RopDeleteFolder` only operates on an empty folder by default - `DEL_MESSAGES`
+ * must be set to also delete the folder's own messages/calendar events/contacts/tasks, and `DEL_FOLDERS` to also
+ * delete (recursively) its subfolders; a non-empty folder deleted without the matching flag fails rather than
+ * silently cascading.
+ *
+ * **Always a soft delete.** `DELETE_HARD_DELETE` is ignored. A permanent delete has to go through restapi's legal
+ * hold check first (the REST routes call `LegalHoldUtils.assertNotOnLegalHold()` for `purge=true`), and that helper
+ * isn't part of `@rapidmx/restapi`'s public exports. A soft-deleted item stays recoverable and discoverable, which is
+ * exactly what a hold requires, so MAPI never purges. Each deleted message is audited as `MESSAGE_DELETE`, like the
+ * REST message route.
+ *
+ * **Bounded.** The subfolder tree is walked iteratively with a visited set (a corrupt `parentFolderUid` cycle
+ * can't loop), at most `MAX_FOLDER_DEPTH` deep and `MAX_FOLDERS_PER_DELETE` wide, and only through folders in the
+ * caller's own mailbox. Items are fetched in explicit, paged queries (a bare `find()` stops at 100 rows, which used
+ * to leave items behind in a folder that was then deleted), up to `MAX_ITEMS_PER_DELETE`. Every query and delete is
+ * charged to the request's `ExecuteBudget` before it runs, so repeating this ROP can't multiply the walk unbounded.
+ *
+ * The request's own `InputHandleIndex` (nominally the *parent* folder of the one being deleted) is validated to
+ * be a real, open folder handle but not cross-checked against the target folder's actual `parentFolderUid` -
+ * the same pragmatic simplification `RopOpenMessageHandler`'s own doc comment documents for its analogous
+ * `FolderId` field.
+ *
+ * @author Jean-Philippe Steinmetz
+ */
+export declare class RopDeleteFolderHandler implements RopHandler {
+    readonly ropId = 29;
+    handle(reader: BufferReader, writer: BufferWriter, context: RopContext): Promise<void>;
+    private writeFailure;
+    /** The repos a folder's items can live in, skipping the optional ones the context doesn't have. */
+    private itemRepos;
+    private hasItems;
+    /**
+     * `rootUid` and every folder below it in the caller's mailbox, children before their parents, or `undefined` when
+     * the tree is deeper than `MAX_FOLDER_DEPTH` or has more than `MAX_FOLDERS_PER_DELETE` folders.
+     */
+    private collectSubtree;
+    /** Soft-deletes `folderUid`'s items within `budget`. Returns `false` if items remain once the budget is spent. */
+    private deleteItems;
+}

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

@@ -0,0 +1,43 @@
+import type { BufferReader, BufferWriter } from "../codec/BufferCursor.js";
+import type { RopContext, RopHandler } from "./RopHandler.js";
+/** Audits a message deleted through MAPI with the same `MESSAGE_DELETE` entry the REST message route records.
+ * Charged to `context.budget` like the `findOne`/`delete` calls around every call site of this function - a real
+ * DB `create()` whenever `context.audit` is configured (the case in every real deployment), so leaving it
+ * uncharged undercounted this loop's real DB work by a third. No-op (and no charge - there's no DB work to
+ * account for) when `context.audit` is absent, the same as an optional-repo item kind this pragmatic subset
+ * already skips charging for. */
+export declare function auditMessageDelete(context: RopContext, message: {
+    uid: string;
+    mailboxUid: string;
+    subject?: string;
+    folderUid: string;
+}): Promise<void>;
+/**
+ * `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,25 @@
+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;
+    readonly responseHandleIndexOffset = 3;
+    handle(reader: BufferReader, writer: BufferWriter, context: RopContext): Promise<void>;
+}