@rapidmx/mapi-plugin 1.0.0-beta.3

package/dist/lib/rop/FastTransferStream.js

@@ -0,0 +1,98 @@
+///////////////////////////////////////////////////////////////////////////////
+// Copyright (C) 2026 Jean-Philippe Steinmetz. All rights reserved.
+// SPDX-License-Identifier: MPL-2.0
+///////////////////////////////////////////////////////////////////////////////
+import { FolderType } from "@rapidmx/restapi";
+import { BufferWriter } from "../codec/BufferCursor.js";
+import { PropertyType, writeTaggedPropertyValue } from "../codec/PropertyValue.js";
+import { resolveFolderCalendarEvents } from "./CalendarEventTarget.js";
+import { resolveFolderMessages } from "./MessageTarget.js";
+import { resolvePropertyValues } from "./PropertyResolvers.js";
+/**
+ * Builds the `FastTransfer` binary stream (`[MS-OXCFXICS]` §2.2.4) `RopFastTransferSourceCopyTo`/
+ * `CopyProperties` hand off to `RopFastTransferSourceGetBuffer` for paging out, per this pragmatic subset's own
+ * "ICS" scope (see the architecture plan's "Incremental sync" row): a **full, non-differential** dump of the
+ * target's current live state, built eagerly and stored whole on the output handle - not the real, much larger
+ * `contentsSync`/`hierarchySync` grammar (`IncrSyncChg`/`IncrSyncDel`/`IncrSyncStateBegin` markers), which
+ * requires a persisted per-device ICS state object (an `IDSET` baseline) this pragmatic subset doesn't
+ * implement. A real client that asks for an incremental sync here simply gets a full re-list every time and
+ * reconciles by diffing against its own local cache - spec-legitimate client behavior, just more state
+ * re-fetched per sync than a byte-perfect ICS server would send, exactly the tradeoff the plan accepts.
+ *
+ * Only the plain `PidTag*` properties this pragmatic subset already resolves via `PropertyResolvers.ts` are
+ * ever included - a Calendar item's own named properties (start/end/location/recurrence/...) are **not**
+ * included in the stream (only `PidTagSubject`), a deliberate scope cut: a client wanting those already has to
+ * `RopOpenMessage`+`RopGetPropertiesSpecific` the item directly (the same "just re-fetches more state" tradeoff
+ * applied one level deeper). No recipients/attachments/subfolders are emitted either - `messageChildren` is
+ * always empty and `Level` (whether to recurse into subfolders) is not honored, matching this pragmatic
+ * subset's existing "no `RopModifyRecipients`" and folder-hierarchy-is-flat-per-call precedents elsewhere.
+ *
+ * @author Jean-Philippe Steinmetz
+ */
+/** FastTransfer markers (`[MS-OXCFXICS]` §2.2.4.1.4, confirmed this session) - only the four this pragmatic
+ * subset's flat, non-differential dump ever needs. */
+const MARKER_START_TOP_FLD = 0x40090003;
+const MARKER_END_FOLDER = 0x400b0003;
+const MARKER_START_MESSAGE = 0x400c0003;
+const MARKER_END_MESSAGE = 0x400d0003;
+/** The well-known columns this pragmatic subset includes by default when the caller (`RopFastTransferSourceCopyTo`)
+ * didn't supply an explicit include list - the same small "what a real client needs" sets `PropertyResolvers.ts`
+ * already defines its own defaults around. */
+const DEFAULT_FOLDER_COLUMNS = [
+    { propertyId: 0x3001, propertyType: PropertyType.PtypString }, // PidTagDisplayName
+    { propertyId: 0x3602, propertyType: PropertyType.PtypInteger32 }, // PidTagContentCount
+    { propertyId: 0x3603, propertyType: PropertyType.PtypInteger32 }, // PidTagContentUnreadCount
+];
+const DEFAULT_MESSAGE_COLUMNS = [
+    { propertyId: 0x0037, propertyType: PropertyType.PtypString }, // PidTagSubject
+    { propertyId: 0x0e07, propertyType: PropertyType.PtypInteger32 }, // PidTagMessageFlags
+    { propertyId: 0x0e1b, propertyType: PropertyType.PtypBoolean }, // PidTagHasAttachments
+    { propertyId: 0x0e06, propertyType: PropertyType.PtypTime }, // PidTagMessageDeliveryTime
+];
+/** A calendar item's named properties are deliberately excluded from the stream (see class doc comment) -
+ * `PidTagSubject` is the only column emitted for one. */
+const DEFAULT_CALENDAR_COLUMNS = [{ propertyId: 0x0037, propertyType: PropertyType.PtypString }];
+async function writePropList(writer, target, columns, context) {
+    const values = await resolvePropertyValues(target, columns, context);
+    columns.forEach((column, index) => writeTaggedPropertyValue(writer, { propertyId: column.propertyId, propertyType: column.propertyType, value: values[index] }));
+}
+function filterExcluded(columns, excludePropertyIds) {
+    return columns.filter((column) => !excludePropertyIds.has(column.propertyId));
+}
+/**
+ * Builds the complete FastTransfer stream for `handle` (a `"folder"` or `"message"` Server object). `columns`,
+ * when given (a `RopFastTransferSourceCopyProperties` explicit include list), replaces every default column set
+ * uniformly at both folder- and message-level; `excludePropertyIds` (a `RopFastTransferSourceCopyTo` exclude
+ * list) is only ever applied to this pragmatic subset's own default columns, per the same reasoning.
+ */
+export async function buildFastTransferStream(handle, context, options = {}) {
+    const writer = new BufferWriter();
+    const exclude = options.excludePropertyIds ?? new Set();
+    if (handle.type === "folder") {
+        const folderColumns = options.columns ?? filterExcluded(DEFAULT_FOLDER_COLUMNS, exclude);
+        writer.writeUInt32LE(MARKER_START_TOP_FLD);
+        await writePropList(writer, handle.entityUid, folderColumns, context);
+        if (handle.entityUid.startsWith("folder:")) {
+            const folderUid = handle.entityUid.slice("folder:".length);
+            const folder = await context.folderRepo.findOne(folderUid, { ignoreACL: true });
+            const isCalendar = folder?.type === FolderType.CALENDAR;
+            const rows = isCalendar
+                ? await resolveFolderCalendarEvents(folderUid, context.calendarEventRepo)
+                : await resolveFolderMessages(folderUid, context.messageRepo);
+            const messageColumns = options.columns ?? filterExcluded(isCalendar ? DEFAULT_CALENDAR_COLUMNS : DEFAULT_MESSAGE_COLUMNS, exclude);
+            for (const row of rows) {
+                writer.writeUInt32LE(MARKER_START_MESSAGE);
+                await writePropList(writer, row, messageColumns, context);
+                writer.writeUInt32LE(MARKER_END_MESSAGE);
+            }
+        }
+        writer.writeUInt32LE(MARKER_END_FOLDER);
+    }
+    else {
+        const isCalendar = handle.entityUid.startsWith("calendarEvent:");
+        const columns = options.columns ?? filterExcluded(isCalendar ? DEFAULT_CALENDAR_COLUMNS : DEFAULT_MESSAGE_COLUMNS, exclude);
+        await writePropList(writer, handle.entityUid, columns, context);
+    }
+    return writer.toBuffer();
+}
+//# sourceMappingURL=FastTransferStream.js.map

package/dist/lib/rop/FastTransferStream.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"FastTransferStream.js","sourceRoot":"","sources":["../../../src/rop/FastTransferStream.ts"],"names":[],"mappings":"AAAA,+EAA+E;AAC/E,mEAAmE;AACnE,mCAAmC;AACnC,+EAA+E;AAC/E,OAAO,EAAU,UAAU,EAAE,MAAM,kBAAkB,CAAC;AACtD,OAAO,EAAE,YAAY,EAAE,MAAM,0BAA0B,CAAC;AACxD,OAAO,EAAE,YAAY,EAAE,wBAAwB,EAAE,MAAM,2BAA2B,CAAC;AAEnF,OAAO,EAAE,2BAA2B,EAAE,MAAM,0BAA0B,CAAC;AACvE,OAAO,EAAE,qBAAqB,EAAE,MAAM,oBAAoB,CAAC;AAC3D,OAAO,EAAE,qBAAqB,EAAE,MAAM,wBAAwB,CAAC;AAG/D;;;;;;;;;;;;;;;;;;;;GAoBG;AAEH;sDACsD;AACtD,MAAM,oBAAoB,GAAG,UAAU,CAAC;AACxC,MAAM,iBAAiB,GAAG,UAAU,CAAC;AACrC,MAAM,oBAAoB,GAAG,UAAU,CAAC;AACxC,MAAM,kBAAkB,GAAG,UAAU,CAAC;AAOtC;;8CAE8C;AAC9C,MAAM,sBAAsB,GAAqB;IAC7C,EAAE,UAAU,EAAE,MAAM,EAAE,YAAY,EAAE,YAAY,CAAC,UAAU,EAAE,EAAE,oBAAoB;IACnF,EAAE,UAAU,EAAE,MAAM,EAAE,YAAY,EAAE,YAAY,CAAC,aAAa,EAAE,EAAE,qBAAqB;IACvF,EAAE,UAAU,EAAE,MAAM,EAAE,YAAY,EAAE,YAAY,CAAC,aAAa,EAAE,EAAE,2BAA2B;CAChG,CAAC;AACF,MAAM,uBAAuB,GAAqB;IAC9C,EAAE,UAAU,EAAE,MAAM,EAAE,YAAY,EAAE,YAAY,CAAC,UAAU,EAAE,EAAE,gBAAgB;IAC/E,EAAE,UAAU,EAAE,MAAM,EAAE,YAAY,EAAE,YAAY,CAAC,aAAa,EAAE,EAAE,qBAAqB;IACvF,EAAE,UAAU,EAAE,MAAM,EAAE,YAAY,EAAE,YAAY,CAAC,WAAW,EAAE,EAAE,uBAAuB;IACvF,EAAE,UAAU,EAAE,MAAM,EAAE,YAAY,EAAE,YAAY,CAAC,QAAQ,EAAE,EAAE,4BAA4B;CAC5F,CAAC;AACF;yDACyD;AACzD,MAAM,wBAAwB,GAAqB,CAAC,EAAE,UAAU,EAAE,MAAM,EAAE,YAAY,EAAE,YAAY,CAAC,UAAU,EAAE,CAAC,CAAC;AAEnH,KAAK,UAAU,aAAa,CACxB,MAAoB,EACpB,MAAc,EACd,OAAyB,EACzB,OAAwH;IAExH,MAAM,MAAM,GAAG,MAAM,qBAAqB,CAAC,MAAM,EAAE,OAAO,EAAE,OAAO,CAAC,CAAC;IACrE,OAAO,CAAC,OAAO,CAAC,CAAC,MAAM,EAAE,KAAK,EAAE,EAAE,CAC9B,wBAAwB,CAAC,MAAM,EAAE,EAAE,UAAU,EAAE,MAAM,CAAC,UAAU,EAAE,YAAY,EAAE,MAAM,CAAC,YAAY,EAAE,KAAK,EAAE,MAAM,CAAC,KAAK,CAAC,EAAE,CAAC,CAC/H,CAAC;AACN,CAAC;AAED,SAAS,cAAc,CAAC,OAAyB,EAAE,kBAAuC;IACtF,OAAO,OAAO,CAAC,MAAM,CAAC,CAAC,MAAM,EAAE,EAAE,CAAC,CAAC,kBAAkB,CAAC,GAAG,CAAC,MAAM,CAAC,UAAU,CAAC,CAAC,CAAC;AAClF,CAAC;AAED;;;;;GAKG;AACH,MAAM,CAAC,KAAK,UAAU,uBAAuB,CACzC,MAAwB,EACxB,OAAmB,EACnB,UAAoF,EAAE;IAEtF,MAAM,MAAM,GAAG,IAAI,YAAY,EAAE,CAAC;IAClC,MAAM,OAAO,GAAG,OAAO,CAAC,kBAAkB,IAAI,IAAI,GAAG,EAAU,CAAC;IAEhE,IAAI,MAAM,CAAC,IAAI,KAAK,QAAQ,EAAE,CAAC;QAC3B,MAAM,aAAa,GAAG,OAAO,CAAC,OAAO,IAAI,cAAc,CAAC,sBAAsB,EAAE,OAAO,CAAC,CAAC;QACzF,MAAM,CAAC,aAAa,CAAC,oBAAoB,CAAC,CAAC;QAC3C,MAAM,aAAa,CAAC,MAAM,EAAE,MAAM,CAAC,SAAS,EAAE,aAAa,EAAE,OAAO,CAAC,CAAC;QAEtE,IAAI,MAAM,CAAC,SAAS,CAAC,UAAU,CAAC,SAAS,CAAC,EAAE,CAAC;YACzC,MAAM,SAAS,GAAG,MAAM,CAAC,SAAS,CAAC,KAAK,CAAC,SAAS,CAAC,MAAM,CAAC,CAAC;YAC3D,MAAM,MAAM,GAAuB,MAAM,OAAO,CAAC,UAAU,CAAC,OAAO,CAAC,SAAS,EAAE,EAAE,SAAS,EAAE,IAAI,EAAE,CAAC,CAAC;YACpG,MAAM,UAAU,GAAG,MAAM,EAAE,IAAI,KAAK,UAAU,CAAC,QAAQ,CAAC;YACxD,MAAM,IAAI,GAAG,UAAU;gBACnB,CAAC,CAAC,MAAM,2BAA2B,CAAC,SAAS,EAAE,OAAO,CAAC,iBAAiB,CAAC;gBACzE,CAAC,CAAC,MAAM,qBAAqB,CAAC,SAAS,EAAE,OAAO,CAAC,WAAW,CAAC,CAAC;YAClE,MAAM,cAAc,GAAG,OAAO,CAAC,OAAO,IAAI,cAAc,CAAC,UAAU,CAAC,CAAC,CAAC,wBAAwB,CAAC,CAAC,CAAC,uBAAuB,EAAE,OAAO,CAAC,CAAC;YAEnI,KAAK,MAAM,GAAG,IAAI,IAAI,EAAE,CAAC;gBACrB,MAAM,CAAC,aAAa,CAAC,oBAAoB,CAAC,CAAC;gBAC3C,MAAM,aAAa,CAAC,MAAM,EAAE,GAAG,EAAE,cAAc,EAAE,OAAO,CAAC,CAAC;gBAC1D,MAAM,CAAC,aAAa,CAAC,kBAAkB,CAAC,CAAC;YAC7C,CAAC;QACL,CAAC;QAED,MAAM,CAAC,aAAa,CAAC,iBAAiB,CAAC,CAAC;IAC5C,CAAC;SAAM,CAAC;QACJ,MAAM,UAAU,GAAG,MAAM,CAAC,SAAS,CAAC,UAAU,CAAC,gBAAgB,CAAC,CAAC;QACjE,MAAM,OAAO,GAAG,OAAO,CAAC,OAAO,IAAI,cAAc,CAAC,UAAU,CAAC,CAAC,CAAC,wBAAwB,CAAC,CAAC,CAAC,uBAAuB,EAAE,OAAO,CAAC,CAAC;QAC5H,MAAM,aAAa,CAAC,MAAM,EAAE,MAAM,CAAC,SAAS,EAAE,OAAO,EAAE,OAAO,CAAC,CAAC;IACpE,CAAC;IAED,OAAO,MAAM,CAAC,QAAQ,EAAE,CAAC;AAC7B,CAAC"}

package/dist/lib/rop/FolderTarget.js

@@ -0,0 +1,111 @@
+/**
+ * Shared helpers for resolving the `"virtual:<name>"`/`"folder:<uid>"` target strings `RopLogonHandler`
+ * assigns to FIDs (see its own doc comment) into real folder data - used by `RopOpenFolderHandler` and
+ * `RopGetHierarchyTableHandler`.
+ */
+/** Display names for the virtual (no real backing `Folder`) special folders - see `RopLogonHandler`'s own
+ * doc comment for why these don't have real rows in this data model. */
+const VIRTUAL_DISPLAY_NAMES = {
+    root: "Root",
+    deferredAction: "Deferred Action",
+    spoolerQueue: "Spooler Queue",
+    ipmSubtree: "Top of Information Store",
+    commonViews: "Common Views",
+    schedule: "Schedule",
+    search: "Finder",
+    views: "Views",
+    shortcuts: "Shortcuts",
+};
+/** Resolves a target string into the display data a folder-table row needs. A `"folder:<uid>"` target whose
+ * `Folder` has since been deleted (soft-deleted or otherwise vanished) degrades to empty-looking values rather
+ * than throwing - the row simply won't be interesting to a client, not a reason to fail the whole ROP. */
+export async function resolveFolderInfo(mailboxUid, target, folderRepo, cache) {
+    if (target.startsWith("folder:")) {
+        const uid = target.slice("folder:".length);
+        const folder = await folderRepo.findOne(uid, { ignoreACL: true });
+        const hasChildren = (await resolveFolderChildren(mailboxUid, target, folderRepo, cache)).length > 0;
+        return {
+            displayName: folder?.name ?? "",
+            unreadCount: folder?.unreadCount ?? 0,
+            totalCount: folder?.totalCount ?? 0,
+            hasChildren,
+        };
+    }
+    const name = target.slice("virtual:".length);
+    const hasChildren = (await resolveFolderChildren(mailboxUid, target, folderRepo, cache)).length > 0;
+    return { displayName: VIRTUAL_DISPLAY_NAMES[name] ?? name, unreadCount: 0, totalCount: 0, hasChildren };
+}
+/**
+ * Resolves the direct children of `target`, as an array of the same target-string format, for
+ * `RopGetHierarchyTable`. Only `"virtual:root"`/`"virtual:ipmSubtree"` (this mailbox's top-level real
+ * folders - both collapse to the same "top of the visible tree" concept in this pragmatic subset, see
+ * `RopLogonHandler`'s own doc comment) and a real folder (its own real children) have any children at all;
+ * every other virtual folder (Deferred Action, Spooler Queue, ...) is permanently empty, since this data
+ * model has no concept of nesting anything under them.
+ *
+ * Filters an already-fetched full folder list in application code rather than querying by
+ * `parentFolderUid: undefined` directly - query-DSL semantics for "field is unset" aren't reliably consistent
+ * across backends (the exact kind of gap this project's own testing philosophy has caught before, e.g. `$or`
+ * being Mongo-only), so filtering a fetched array sidesteps the question entirely rather than risking it.
+ * The comparison itself uses `== null` (matching both `null` and `undefined`), not `=== undefined` - a
+ * top-level folder's unset `parentFolderUid` round-trips as genuine `undefined` from Mongo but as `null` from
+ * a SQL `nullable` column, a real, previously-confirmed cross-backend discrepancy in this codebase (caught by
+ * this exact test against a real SQLite-backed server, not assumed).
+ *
+ * **`cache`**: without it, this fetches every folder in the mailbox on every call - fine for the single call
+ * `RopGetHierarchyTableHandler` makes to build a table, but `resolveFolderInfo` also calls this once per row
+ * just to compute `hasChildren`, and a table page can hold many rows. A caller resolving a whole page (
+ * `RopQueryRowsHandler`/`RopGetPropertiesSpecificHandler`) passes one shared cache object through every call in
+ * that batch so the full list is fetched at most once per batch instead of once per row - see
+ * `FolderResolutionCache`'s own doc comment for why this isn't session state.
+ */
+export async function resolveFolderChildren(mailboxUid, target, folderRepo, cache) {
+    const isTopLevel = target === "virtual:root" || target === "virtual:ipmSubtree";
+    let parentFolderUid;
+    if (isTopLevel) {
+        parentFolderUid = undefined;
+    }
+    else if (target.startsWith("folder:")) {
+        parentFolderUid = target.slice("folder:".length);
+    }
+    else {
+        return [];
+    }
+    let allFolders;
+    if (cache) {
+        cache.allFolders ?? (cache.allFolders = await folderRepo.find({ mailboxUid }, { ignoreACL: true }));
+        allFolders = cache.allFolders;
+    }
+    else {
+        allFolders = await folderRepo.find({ mailboxUid }, { ignoreACL: true });
+    }
+    return allFolders
+        .filter((f) => (isTopLevel ? f.parentFolderUid == null : f.parentFolderUid === parentFolderUid))
+        .map((f) => `folder:${f.uid}`);
+}
+/**
+ * Returns `target`'s existing FID if `RopLogon` or an earlier `RopGetHierarchyTable` row already assigned
+ * one, otherwise assigns and remembers the next free small integer FID. This is what lets a client
+ * `RopOpenFolder` a child folder it only ever learned about via a `RopQueryRows` row's `PidTagFolderId`
+ * column - without this, only the 13 `RopLogon`-time special folders could ever be opened.
+ *
+ * Backed by `session.folderTargetIds` (target -> FID) and `session.nextFolderId`, an O(1) reverse index/counter
+ * pair rather than a linear scan of `session.folderIds` plus a `Math.max(...spread)` over its keys - both real
+ * costs, not just theoretical ones: `folderTargetIds` only ever grows for a session's lifetime as a client
+ * browses more of a mailbox's folder tree, so the old scan-per-lookup approach was quadratic across a session
+ * that opens many folders, and `Math.max` spreading an unbounded array as call arguments risked a stack
+ * overflow past V8's argument-count limit on a mailbox with enough folders. `RopLogonHandler` keeps
+ * `folderTargetIds`/`nextFolderId` in sync with `folderIds` for the 13 special folders it assigns directly,
+ * rather than going through this function, since it assigns all 13 as one batch up front.
+ */
+export function assignOrGetFid(session, target) {
+    const existing = session.folderTargetIds[target];
+    if (existing !== undefined) {
+        return existing;
+    }
+    const fid = session.nextFolderId++;
+    session.folderIds[String(fid)] = target;
+    session.folderTargetIds[target] = fid;
+    return fid;
+}
+//# sourceMappingURL=FolderTarget.js.map

package/dist/lib/rop/FolderTarget.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"FolderTarget.js","sourceRoot":"","sources":["../../../src/rop/FolderTarget.ts"],"names":[],"mappings":"AAQA;;;;GAIG;AAEH;wEACwE;AACxE,MAAM,qBAAqB,GAA2B;IAClD,IAAI,EAAE,MAAM;IACZ,cAAc,EAAE,iBAAiB;IACjC,YAAY,EAAE,eAAe;IAC7B,UAAU,EAAE,0BAA0B;IACtC,WAAW,EAAE,cAAc;IAC3B,QAAQ,EAAE,UAAU;IACpB,MAAM,EAAE,QAAQ;IAChB,KAAK,EAAE,OAAO;IACd,SAAS,EAAE,WAAW;CACzB,CAAC;AAmBF;;0GAE0G;AAC1G,MAAM,CAAC,KAAK,UAAU,iBAAiB,CACnC,UAAkB,EAClB,MAAc,EACd,UAA0B,EAC1B,KAA6B;IAE7B,IAAI,MAAM,CAAC,UAAU,CAAC,SAAS,CAAC,EAAE,CAAC;QAC/B,MAAM,GAAG,GAAG,MAAM,CAAC,KAAK,CAAC,SAAS,CAAC,MAAM,CAAC,CAAC;QAC3C,MAAM,MAAM,GAAuB,MAAM,UAAU,CAAC,OAAO,CAAC,GAAG,EAAE,EAAE,SAAS,EAAE,IAAI,EAAE,CAAC,CAAC;QACtF,MAAM,WAAW,GAAG,CAAC,MAAM,qBAAqB,CAAC,UAAU,EAAE,MAAM,EAAE,UAAU,EAAE,KAAK,CAAC,CAAC,CAAC,MAAM,GAAG,CAAC,CAAC;QACpG,OAAO;YACH,WAAW,EAAE,MAAM,EAAE,IAAI,IAAI,EAAE;YAC/B,WAAW,EAAE,MAAM,EAAE,WAAW,IAAI,CAAC;YACrC,UAAU,EAAE,MAAM,EAAE,UAAU,IAAI,CAAC;YACnC,WAAW;SACd,CAAC;IACN,CAAC;IACD,MAAM,IAAI,GAAG,MAAM,CAAC,KAAK,CAAC,UAAU,CAAC,MAAM,CAAC,CAAC;IAC7C,MAAM,WAAW,GAAG,CAAC,MAAM,qBAAqB,CAAC,UAAU,EAAE,MAAM,EAAE,UAAU,EAAE,KAAK,CAAC,CAAC,CAAC,MAAM,GAAG,CAAC,CAAC;IACpG,OAAO,EAAE,WAAW,EAAE,qBAAqB,CAAC,IAAI,CAAC,IAAI,IAAI,EAAE,WAAW,EAAE,CAAC,EAAE,UAAU,EAAE,CAAC,EAAE,WAAW,EAAE,CAAC;AAC5G,CAAC;AAED;;;;;;;;;;;;;;;;;;;;;;;GAuBG;AACH,MAAM,CAAC,KAAK,UAAU,qBAAqB,CACvC,UAAkB,EAClB,MAAc,EACd,UAA0B,EAC1B,KAA6B;IAE7B,MAAM,UAAU,GAAG,MAAM,KAAK,cAAc,IAAI,MAAM,KAAK,oBAAoB,CAAC;IAChF,IAAI,eAAmC,CAAC;IACxC,IAAI,UAAU,EAAE,CAAC;QACb,eAAe,GAAG,SAAS,CAAC;IAChC,CAAC;SAAM,IAAI,MAAM,CAAC,UAAU,CAAC,SAAS,CAAC,EAAE,CAAC;QACtC,eAAe,GAAG,MAAM,CAAC,KAAK,CAAC,SAAS,CAAC,MAAM,CAAC,CAAC;IACrD,CAAC;SAAM,CAAC;QACJ,OAAO,EAAE,CAAC;IACd,CAAC;IAED,IAAI,UAAoB,CAAC;IACzB,IAAI,KAAK,EAAE,CAAC;QACR,KAAK,CAAC,UAAU,KAAhB,KAAK,CAAC,UAAU,GAAK,MAAM,UAAU,CAAC,IAAI,CAAC,EAAE,UAAU,EAAE,EAAE,EAAE,SAAS,EAAE,IAAI,EAAE,CAAC,EAAC;QAChF,UAAU,GAAG,KAAK,CAAC,UAAU,CAAC;IAClC,CAAC;SAAM,CAAC;QACJ,UAAU,GAAG,MAAM,UAAU,CAAC,IAAI,CAAC,EAAE,UAAU,EAAE,EAAE,EAAE,SAAS,EAAE,IAAI,EAAE,CAAC,CAAC;IAC5E,CAAC;IACD,OAAO,UAAU;SACZ,MAAM,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,UAAU,CAAC,CAAC,CAAC,CAAC,CAAC,eAAe,IAAI,IAAI,CAAC,CAAC,CAAC,CAAC,CAAC,eAAe,KAAK,eAAe,CAAC,CAAC;SAC/F,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,UAAU,CAAC,CAAC,GAAG,EAAE,CAAC,CAAC;AACvC,CAAC;AAED;;;;;;;;;;;;;;GAcG;AACH,MAAM,UAAU,cAAc,CAAC,OAA2B,EAAE,MAAc;IACtE,MAAM,QAAQ,GAAG,OAAO,CAAC,eAAe,CAAC,MAAM,CAAC,CAAC;IACjD,IAAI,QAAQ,KAAK,SAAS,EAAE,CAAC;QACzB,OAAO,QAAQ,CAAC;IACpB,CAAC;IACD,MAAM,GAAG,GAAG,OAAO,CAAC,YAAY,EAAE,CAAC;IACnC,OAAO,CAAC,SAAS,CAAC,MAAM,CAAC,GAAG,CAAC,CAAC,GAAG,MAAM,CAAC;IACxC,OAAO,CAAC,eAAe,CAAC,MAAM,CAAC,GAAG,GAAG,CAAC;IACtC,OAAO,GAAG,CAAC;AACf,CAAC"}

package/dist/lib/rop/MeetingMessageClassHandler.js

@@ -0,0 +1,95 @@
+///////////////////////////////////////////////////////////////////////////////
+// Copyright (C) 2026 Jean-Philippe Steinmetz. All rights reserved.
+// SPDX-License-Identifier: MPL-2.0
+///////////////////////////////////////////////////////////////////////////////
+import { AttendeeResponseStatus } from "@rapidmx/restapi";
+import { BufferReader } from "../codec/BufferCursor.js";
+import { decodeGlobalObjectId } from "../codec/GlobalObjectId.js";
+import { LID_GLOBAL_OBJECT_ID, PSETID_MEETING } from "./CalendarNamedProperties.js";
+import { resolveNamedProperty } from "./NamedPropertyRegistry.js";
+/** `PidTagMessageClass` suffix -> the caller's own new `AttendeeResponseStatus`, per `[MS-OXOCAL]`'s meeting
+ * response object naming convention. An unrecognized suffix (a message class this pragmatic subset doesn't
+ * know how to interpret as a response) is simply not handled - see `submitMeetingResponse`'s own doc comment. */
+const RESPONSE_STATUS_BY_MESSAGE_CLASS = {
+    "IPM.Schedule.Meeting.Resp.Pos": AttendeeResponseStatus.ACCEPTED,
+    "IPM.Schedule.Meeting.Resp.Tent": AttendeeResponseStatus.TENTATIVE,
+    "IPM.Schedule.Meeting.Resp.Neg": AttendeeResponseStatus.DECLINED,
+};
+/** Scans `properties` (a draft handle's accumulated `RopSetProperties` values) for the one already-assigned
+ * named property matching `(guid, lid)`, returning its raw stored string value - the single-property analog of
+ * `RopSaveChangesMessageHandler.ts`'s own full-table decode loop, needed here only for `PidLidGlobalObjectId`. */
+function findNamedPropertyValue(session, properties, guid, lid) {
+    for (const [key, value] of Object.entries(properties)) {
+        const propertyId = Number(key);
+        if (propertyId < 0x8000) {
+            continue;
+        }
+        const named = resolveNamedProperty(session, propertyId);
+        if (named && named.kind === "lid" && named.lid === lid && named.guid.toLowerCase() === guid) {
+            return value;
+        }
+    }
+    return undefined;
+}
+/**
+ * Handles a submitted `"IPM.Schedule.Meeting.Resp.{Pos,Neg,Tent}"` message - an attendee's own response to a
+ * meeting invite this server previously sent (`RopSubmitMessageHandler.submitAppointment`). Delegated to from
+ * `RopSubmitMessageHandler` for that message-class prefix, instead of the ordinary mail or Appointment paths.
+ *
+ * Correlates the response back to the original `CalendarEvent` via `PidLidGlobalObjectId` (echoed by a real
+ * client from the invite it's responding to - see `GlobalObjectId.ts`'s own doc comment for why this requires
+ * no separate correlation table) and updates the caller's own `Attendee.responseStatus` in place, reusing the
+ * exact same matching-by-mailbox-address logic `MeetingResponseCommand` (EAS's own `MeetingResponse` handler)
+ * already implements - this is a from-scratch reimplementation of that small algorithm rather than a
+ * cross-import, since EAS and MAPI are independent protocol verticals in this codebase with no dependency
+ * between them.
+ *
+ * Every failure mode here (no `PidLidGlobalObjectId` set, no matching `CalendarEvent`, no resolvable mailbox,
+ * caller isn't actually an attendee, unrecognized message-class suffix) is a silent no-op rather than an error
+ * response - the same "don't fail the whole ROP over a stale/unresolvable reference" principle this pragmatic
+ * subset applies throughout (e.g. `MessageTarget.resolveMessageInfo`'s own doc comment). A response that can't
+ * be correlated or applied is simply dropped, not a reason to reject the client's `RopSubmitMessage` call.
+ *
+ * **The one query in this package that isn't `mailboxUid`-scoped, and why that's unavoidable here**: unlike
+ * every other `ignoreACL: true` repo call in this codebase (all transitively scoped to the caller's own
+ * mailbox via a session FID/MID registry that itself only ever gets populated from mailbox-scoped queries),
+ * `calendarEventRepo.find({ icalUid })` below deliberately searches *every* mailbox on this server - the
+ * `CalendarEvent` being responded to belongs to the meeting's *organizer*, who is very often a different
+ * mailbox than the attendee submitting this response, and the caller's own session has no way to know which
+ * mailbox that is. Safety instead comes from two independent properties: `icalUid` is a server-generated
+ * `crypto.randomUUID()` (see `RopSaveChangesMessageHandler.saveAppointment`), for all practical purposes
+ * globally unique, so this can't be used to enumerate or collide with another organizer's events; and the
+ * actual authorization gate is the attendee-membership check a few lines down (`callerAddresses.has(...)`),
+ * derived entirely from *this* caller's own resolved mailbox record, not from anything the client supplied -
+ * a crafted `PidLidGlobalObjectId` can at best name a real `icalUid` it doesn't already know the value of
+ * (astronomically unlikely against a random UUID) and still can't mutate an event unless the caller's own
+ * mailbox is genuinely a listed attendee on it.
+ */
+export async function submitMeetingResponse(messageClass, draftProperties, context) {
+    const responseStatus = RESPONSE_STATUS_BY_MESSAGE_CLASS[messageClass];
+    if (!responseStatus) {
+        return;
+    }
+    const globalObjectIdBase64 = findNamedPropertyValue(context.session, draftProperties, PSETID_MEETING, LID_GLOBAL_OBJECT_ID);
+    if (!globalObjectIdBase64) {
+        return;
+    }
+    const icalUid = decodeGlobalObjectId(new BufferReader(Buffer.from(globalObjectIdBase64, "base64")));
+    const events = await context.calendarEventRepo.find({ icalUid }, { ignoreACL: true, limit: 1 });
+    const event = events[0];
+    if (!event) {
+        return;
+    }
+    const mailbox = await context.mailboxRepo.findOne(context.mailboxUid, { ignoreACL: true });
+    if (!mailbox) {
+        return;
+    }
+    const callerAddresses = new Set([mailbox.primarySmtpAddress.toLowerCase(), ...mailbox.aliasAddresses.map((a) => a.toLowerCase())]);
+    const attendeeIndex = event.attendees.findIndex((attendee) => callerAddresses.has(attendee.address.toLowerCase()));
+    if (attendeeIndex === -1) {
+        return;
+    }
+    const attendees = event.attendees.map((attendee, i) => (i === attendeeIndex ? { ...attendee, responseStatus } : attendee));
+    await context.calendarEventRepo.update({ uid: event.uid, version: event.version, attendees }, event, { ignoreACL: true });
+}
+//# sourceMappingURL=MeetingMessageClassHandler.js.map

package/dist/lib/rop/MeetingMessageClassHandler.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"MeetingMessageClassHandler.js","sourceRoot":"","sources":["../../../src/rop/MeetingMessageClassHandler.ts"],"names":[],"mappings":"AAAA,+EAA+E;AAC/E,mEAAmE;AACnE,mCAAmC;AACnC,+EAA+E;AAC/E,OAAO,EAAE,sBAAsB,EAAqC,MAAM,kBAAkB,CAAC;AAC7F,OAAO,EAAE,YAAY,EAAE,MAAM,0BAA0B,CAAC;AACxD,OAAO,EAAE,oBAAoB,EAAE,MAAM,4BAA4B,CAAC;AAElE,OAAO,EAAE,oBAAoB,EAAE,cAAc,EAAE,MAAM,8BAA8B,CAAC;AACpF,OAAO,EAAE,oBAAoB,EAAE,MAAM,4BAA4B,CAAC;AAGlE;;iHAEiH;AACjH,MAAM,gCAAgC,GAA2C;IAC7E,+BAA+B,EAAE,sBAAsB,CAAC,QAAQ;IAChE,gCAAgC,EAAE,sBAAsB,CAAC,SAAS;IAClE,+BAA+B,EAAE,sBAAsB,CAAC,QAAQ;CACnE,CAAC;AAEF;;kHAEkH;AAClH,SAAS,sBAAsB,CAAC,OAA2B,EAAE,UAAkC,EAAE,IAAY,EAAE,GAAW;IACtH,KAAK,MAAM,CAAC,GAAG,EAAE,KAAK,CAAC,IAAI,MAAM,CAAC,OAAO,CAAC,UAAU,CAAC,EAAE,CAAC;QACpD,MAAM,UAAU,GAAG,MAAM,CAAC,GAAG,CAAC,CAAC;QAC/B,IAAI,UAAU,GAAG,MAAM,EAAE,CAAC;YACtB,SAAS;QACb,CAAC;QACD,MAAM,KAAK,GAAG,oBAAoB,CAAC,OAAO,EAAE,UAAU,CAAC,CAAC;QACxD,IAAI,KAAK,IAAI,KAAK,CAAC,IAAI,KAAK,KAAK,IAAI,KAAK,CAAC,GAAG,KAAK,GAAG,IAAI,KAAK,CAAC,IAAI,CAAC,WAAW,EAAE,KAAK,IAAI,EAAE,CAAC;YAC1F,OAAO,KAAK,CAAC;QACjB,CAAC;IACL,CAAC;IACD,OAAO,SAAS,CAAC;AACrB,CAAC;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAiCG;AACH,MAAM,CAAC,KAAK,UAAU,qBAAqB,CAAC,YAAoB,EAAE,eAAuC,EAAE,OAAmB;IAC1H,MAAM,cAAc,GAAG,gCAAgC,CAAC,YAAY,CAAC,CAAC;IACtE,IAAI,CAAC,cAAc,EAAE,CAAC;QAClB,OAAO;IACX,CAAC;IAED,MAAM,oBAAoB,GAAG,sBAAsB,CAAC,OAAO,CAAC,OAAO,EAAE,eAAe,EAAE,cAAc,EAAE,oBAAoB,CAAC,CAAC;IAC5H,IAAI,CAAC,oBAAoB,EAAE,CAAC;QACxB,OAAO;IACX,CAAC;IACD,MAAM,OAAO,GAAG,oBAAoB,CAAC,IAAI,YAAY,CAAC,MAAM,CAAC,IAAI,CAAC,oBAAoB,EAAE,QAAQ,CAAC,CAAC,CAAC,CAAC;IAEpG,MAAM,MAAM,GAAyD,MAAM,OAAO,CAAC,iBAAiB,CAAC,IAAI,CACrG,EAAE,OAAO,EAAE,EACX,EAAE,SAAS,EAAE,IAAI,EAAE,KAAK,EAAE,CAAC,EAAE,CAChC,CAAC;IACF,MAAM,KAAK,GAAG,MAAM,CAAC,CAAC,CAAC,CAAC;IACxB,IAAI,CAAC,KAAK,EAAE,CAAC;QACT,OAAO;IACX,CAAC;IAED,MAAM,OAAO,GAAG,MAAM,OAAO,CAAC,WAAW,CAAC,OAAO,CAAC,OAAO,CAAC,UAAU,EAAE,EAAE,SAAS,EAAE,IAAI,EAAE,CAAC,CAAC;IAC3F,IAAI,CAAC,OAAO,EAAE,CAAC;QACX,OAAO;IACX,CAAC;IACD,MAAM,eAAe,GAAG,IAAI,GAAG,CAAC,CAAC,OAAO,CAAC,kBAAkB,CAAC,WAAW,EAAE,EAAE,GAAG,OAAO,CAAC,cAAc,CAAC,GAAG,CAAC,CAAC,CAAS,EAAE,EAAE,CAAC,CAAC,CAAC,WAAW,EAAE,CAAC,CAAC,CAAC,CAAC;IAC3I,MAAM,aAAa,GAAG,KAAK,CAAC,SAAS,CAAC,SAAS,CAAC,CAAC,QAAQ,EAAE,EAAE,CAAC,eAAe,CAAC,GAAG,CAAC,QAAQ,CAAC,OAAO,CAAC,WAAW,EAAE,CAAC,CAAC,CAAC;IACnH,IAAI,aAAa,KAAK,CAAC,CAAC,EAAE,CAAC;QACvB,OAAO;IACX,CAAC;IAED,MAAM,SAAS,GAAe,KAAK,CAAC,SAAS,CAAC,GAAG,CAAC,CAAC,QAAQ,EAAE,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,KAAK,aAAa,CAAC,CAAC,CAAC,EAAE,GAAG,QAAQ,EAAE,cAAc,EAAE,CAAC,CAAC,CAAC,QAAQ,CAAC,CAAC,CAAC;IACvI,MAAM,OAAO,CAAC,iBAAiB,CAAC,MAAM,CAAC,EAAE,GAAG,EAAE,KAAK,CAAC,GAAG,EAAE,OAAO,EAAE,KAAK,CAAC,OAAO,EAAE,SAAS,EAAE,EAAE,KAAK,EAAE,EAAE,SAAS,EAAE,IAAI,EAAE,CAAC,CAAC;AAC9H,CAAC"}

package/dist/lib/rop/MessageBodyStream.js

@@ -0,0 +1,42 @@
+///////////////////////////////////////////////////////////////////////////////
+// Copyright (C) 2026 Jean-Philippe Steinmetz. All rights reserved.
+// SPDX-License-Identifier: MPL-2.0
+///////////////////////////////////////////////////////////////////////////////
+import { simpleParser } from "mailparser";
+import { BufferWriter } from "../codec/BufferCursor.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 const PID_TAG_BODY = 0x1000;
+/**
+ * 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.
+ *
+ * Recomputed on every call rather than cached anywhere (including on the `"stream"` handle itself) -
+ * `MapiSessionContext` is serialized through `RedisCache`'s JSON round trip for multi-instance deployments, so
+ * a raw `Buffer` stored there wouldn't survive it (the same class of gap this codebase already documented for
+ * `Date` fields, see `MapiSessionContext`'s own doc comment). A documented, pragmatic trade-off: a large body
+ * read across several `RopReadStream` calls re-parses the MIME source each time rather than once - correct,
+ * not byte-perfect-efficient.
+ */
+export async function resolveMessageBodyBytes(target, messageRepo, blobStore) {
+    const uid = target.slice("message:".length);
+    const message = await messageRepo.findOne(uid, { ignoreACL: true });
+    if (!message) {
+        return Buffer.alloc(0);
+    }
+    const raw = await blobStore.get(message.bodyBlobKey);
+    const parsed = await simpleParser(raw);
+    const writer = new BufferWriter();
+    writer.writeNullTerminatedUtf16LE(parsed.text ?? "");
+    return writer.toBuffer();
+}
+//# sourceMappingURL=MessageBodyStream.js.map

package/dist/lib/rop/MessageBodyStream.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"MessageBodyStream.js","sourceRoot":"","sources":["../../../src/rop/MessageBodyStream.ts"],"names":[],"mappings":"AAAA,+EAA+E;AAC/E,mEAAmE;AACnE,mCAAmC;AACnC,+EAA+E;AAC/E,OAAO,EAAE,YAAY,EAAE,MAAM,YAAY,CAAC;AAG1C,OAAO,EAAE,YAAY,EAAE,MAAM,0BAA0B,CAAC;AAExD;;oEAEoE;AACpE,MAAM,CAAC,MAAM,YAAY,GAAG,MAAM,CAAC;AAEnC;;;;;;;;;;;;;;;;;;GAkBG;AACH,MAAM,CAAC,KAAK,UAAU,uBAAuB,CAAC,MAAc,EAAE,WAA2B,EAAE,SAAoB;IAC3G,MAAM,GAAG,GAAG,MAAM,CAAC,KAAK,CAAC,UAAU,CAAC,MAAM,CAAC,CAAC;IAC5C,MAAM,OAAO,GAAwB,MAAM,WAAW,CAAC,OAAO,CAAC,GAAG,EAAE,EAAE,SAAS,EAAE,IAAI,EAAE,CAAC,CAAC;IACzF,IAAI,CAAC,OAAO,EAAE,CAAC;QACX,OAAO,MAAM,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC;IAC3B,CAAC;IACD,MAAM,GAAG,GAAG,MAAM,SAAS,CAAC,GAAG,CAAC,OAAO,CAAC,WAAW,CAAC,CAAC;IACrD,MAAM,MAAM,GAAG,MAAM,YAAY,CAAC,GAAG,CAAC,CAAC;IACvC,MAAM,MAAM,GAAG,IAAI,YAAY,EAAE,CAAC;IAClC,MAAM,CAAC,0BAA0B,CAAC,MAAM,CAAC,IAAI,IAAI,EAAE,CAAC,CAAC;IACrD,OAAO,MAAM,CAAC,QAAQ,EAAE,CAAC;AAC7B,CAAC"}

package/dist/lib/rop/MessageTarget.js

@@ -0,0 +1,44 @@
+/** 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 async function resolveMessageInfo(target, messageRepo) {
+    const uid = target.slice("message:".length);
+    const message = await messageRepo.findOne(uid, { ignoreACL: true });
+    return {
+        subject: message?.subject ?? "",
+        read: message?.flags?.read ?? false,
+        hasAttachments: message?.hasAttachments ?? false,
+        receivedDate: message?.receivedDate ?? new Date(0),
+        labelUids: message?.labelUids ?? [],
+    };
+}
+/** Resolves the messages directly in `folderUid`, as `"message:<uid>"` target strings, for
+ * `RopGetContentsTable`. */
+export async function resolveFolderMessages(folderUid, messageRepo) {
+    const messages = await messageRepo.find({ folderUid }, { ignoreACL: true });
+    return messages.map((m) => `message:${m.uid}`);
+}
+/**
+ * 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 function assignOrGetMid(session, target) {
+    const existing = session.messageTargetIds[target];
+    if (existing !== undefined) {
+        return existing;
+    }
+    const mid = session.nextMessageId++;
+    session.messageIds[String(mid)] = target;
+    session.messageTargetIds[target] = mid;
+    return mid;
+}
+//# sourceMappingURL=MessageTarget.js.map

package/dist/lib/rop/MessageTarget.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"MessageTarget.js","sourceRoot":"","sources":["../../../src/rop/MessageTarget.ts"],"names":[],"mappings":"AAwBA;;uDAEuD;AACvD,MAAM,CAAC,KAAK,UAAU,kBAAkB,CAAC,MAAc,EAAE,WAA2B;IAChF,MAAM,GAAG,GAAG,MAAM,CAAC,KAAK,CAAC,UAAU,CAAC,MAAM,CAAC,CAAC;IAC5C,MAAM,OAAO,GAAwB,MAAM,WAAW,CAAC,OAAO,CAAC,GAAG,EAAE,EAAE,SAAS,EAAE,IAAI,EAAE,CAAC,CAAC;IACzF,OAAO;QACH,OAAO,EAAE,OAAO,EAAE,OAAO,IAAI,EAAE;QAC/B,IAAI,EAAE,OAAO,EAAE,KAAK,EAAE,IAAI,IAAI,KAAK;QACnC,cAAc,EAAE,OAAO,EAAE,cAAc,IAAI,KAAK;QAChD,YAAY,EAAE,OAAO,EAAE,YAAY,IAAI,IAAI,IAAI,CAAC,CAAC,CAAC;QAClD,SAAS,EAAE,OAAO,EAAE,SAAS,IAAI,EAAE;KACtC,CAAC;AACN,CAAC;AAED;4BAC4B;AAC5B,MAAM,CAAC,KAAK,UAAU,qBAAqB,CAAC,SAAiB,EAAE,WAA2B;IACtF,MAAM,QAAQ,GAAc,MAAM,WAAW,CAAC,IAAI,CAAC,EAAE,SAAS,EAAE,EAAE,EAAE,SAAS,EAAE,IAAI,EAAE,CAAC,CAAC;IACvF,OAAO,QAAQ,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,WAAW,CAAC,CAAC,GAAG,EAAE,CAAC,CAAC;AACnD,CAAC;AAED;;;;;;;;;;;;GAYG;AACH,MAAM,UAAU,cAAc,CAAC,OAA2B,EAAE,MAAc;IACtE,MAAM,QAAQ,GAAG,OAAO,CAAC,gBAAgB,CAAC,MAAM,CAAC,CAAC;IAClD,IAAI,QAAQ,KAAK,SAAS,EAAE,CAAC;QACzB,OAAO,QAAQ,CAAC;IACpB,CAAC;IACD,MAAM,GAAG,GAAG,OAAO,CAAC,aAAa,EAAE,CAAC;IACpC,OAAO,CAAC,UAAU,CAAC,MAAM,CAAC,GAAG,CAAC,CAAC,GAAG,MAAM,CAAC;IACzC,OAAO,CAAC,gBAAgB,CAAC,MAAM,CAAC,GAAG,GAAG,CAAC;IACvC,OAAO,GAAG,CAAC;AACf,CAAC"}

package/dist/lib/rop/NamedPropertyRegistry.js

@@ -0,0 +1,66 @@
+/** The first numeric property ID this pragmatic subset ever assigns to a named property - real Exchange also
+ * reserves the `0x0000`-`0x7FFF` range for well-known/`PidTag*` properties, only ever assigning named
+ * properties IDs at `0x8000` and above (`[MS-OXCPRPT]`'s own `RopGetPropertyIdsFromNames` processing rules). */
+const FIRST_NAMED_PROPERTY_ID = 0x8000;
+/** A `PropertyName`'s registry key - a JSON string rather than a delimiter-joined one (e.g. `"<guid>:<lid>"`)
+ * because a string-`Kind` named property's own `name` is an arbitrary client-supplied string that could
+ * legitimately contain any delimiter this codec might otherwise pick (some real named properties do use
+ * URN-shaped names). `JSON.stringify` on a small, fixed-shape object has no such ambiguity. */
+function keyFor(propertyName) {
+    return propertyName.kind === "lid"
+        ? JSON.stringify({ guid: propertyName.guid.toLowerCase(), kind: "lid", lid: propertyName.lid })
+        : JSON.stringify({ guid: propertyName.guid.toLowerCase(), kind: "name", name: propertyName.name });
+}
+/** The highest numeric property ID a `PropertyTag`'s 16-bit `PropertyId` field can carry at all - not a
+ * pragmatic-subset choice, an absolute wire-format ceiling (`writeUInt16LE` cannot encode anything past this). */
+const LAST_NAMED_PROPERTY_ID = 0xffff;
+/**
+ * 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` (32,768 distinct names already registered
+ * this session - the entire `0x8000`-`0xFFFF` numeric ID space this pragmatic subset has to hand out), 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 function assignOrGetNamedPropertyId(session, propertyName) {
+    const key = keyFor(propertyName);
+    const existing = session.namedProperties[key];
+    if (existing !== undefined) {
+        return existing;
+    }
+    if (session.nextNamedPropertyId > LAST_NAMED_PROPERTY_ID) {
+        return 0x0000;
+    }
+    const id = session.nextNamedPropertyId++;
+    session.namedProperties[key] = id;
+    session.namedPropertyIds[id] = key;
+    return id;
+}
+/** 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 function resolveNamedProperty(session, propertyId) {
+    const key = session.namedPropertyIds[propertyId];
+    return key !== undefined ? JSON.parse(key) : undefined;
+}
+//# sourceMappingURL=NamedPropertyRegistry.js.map

package/dist/lib/rop/NamedPropertyRegistry.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"NamedPropertyRegistry.js","sourceRoot":"","sources":["../../../src/rop/NamedPropertyRegistry.ts"],"names":[],"mappings":"AAmBA;;gHAEgH;AAChH,MAAM,uBAAuB,GAAG,MAAM,CAAC;AAEvC;;;+FAG+F;AAC/F,SAAS,MAAM,CAAC,YAA0B;IACtC,OAAO,YAAY,CAAC,IAAI,KAAK,KAAK;QAC9B,CAAC,CAAC,IAAI,CAAC,SAAS,CAAC,EAAE,IAAI,EAAE,YAAY,CAAC,IAAI,CAAC,WAAW,EAAE,EAAE,IAAI,EAAE,KAAK,EAAE,GAAG,EAAE,YAAY,CAAC,GAAG,EAAE,CAAC;QAC/F,CAAC,CAAC,IAAI,CAAC,SAAS,CAAC,EAAE,IAAI,EAAE,YAAY,CAAC,IAAI,CAAC,WAAW,EAAE,EAAE,IAAI,EAAE,MAAM,EAAE,IAAI,EAAE,YAAY,CAAC,IAAI,EAAE,CAAC,CAAC;AAC3G,CAAC;AAED;kHACkH;AAClH,MAAM,sBAAsB,GAAG,MAAM,CAAC;AAEtC;;;;;;;;;;;;;;;;;;;;;;;;GAwBG;AACH,MAAM,UAAU,0BAA0B,CAAC,OAA2B,EAAE,YAA0B;IAC9F,MAAM,GAAG,GAAG,MAAM,CAAC,YAAY,CAAC,CAAC;IACjC,MAAM,QAAQ,GAAG,OAAO,CAAC,eAAe,CAAC,GAAG,CAAC,CAAC;IAC9C,IAAI,QAAQ,KAAK,SAAS,EAAE,CAAC;QACzB,OAAO,QAAQ,CAAC;IACpB,CAAC;IACD,IAAI,OAAO,CAAC,mBAAmB,GAAG,sBAAsB,EAAE,CAAC;QACvD,OAAO,MAAM,CAAC;IAClB,CAAC;IACD,MAAM,EAAE,GAAG,OAAO,CAAC,mBAAmB,EAAE,CAAC;IACzC,OAAO,CAAC,eAAe,CAAC,GAAG,CAAC,GAAG,EAAE,CAAC;IAClC,OAAO,CAAC,gBAAgB,CAAC,EAAE,CAAC,GAAG,GAAG,CAAC;IACnC,OAAO,EAAE,CAAC;AACd,CAAC;AAED;;;;;qBAKqB;AACrB,MAAM,UAAU,oBAAoB,CAAC,OAA2B,EAAE,UAAkB;IAChF,MAAM,GAAG,GAAG,OAAO,CAAC,gBAAgB,CAAC,UAAU,CAAC,CAAC;IACjD,OAAO,GAAG,KAAK,SAAS,CAAC,CAAC,CAAE,IAAI,CAAC,KAAK,CAAC,GAAG,CAAkB,CAAC,CAAC,CAAC,SAAS,CAAC;AAC7E,CAAC"}