[jayzuccarelli]

Builds on #1 (the repository skeleton); the first commit here is that branch, so review from the strawman commits on, or after #1 merges.

Strawman for the Resource operations SEP in the Filesystems WG charter, to give the group something concrete to review and change.

• docs/proposals/resource-operations.md: resources/stat, resources/create (create-if-absent), resources/update (requires ifMatch), resources/delete (optional ifMatch); an opaque version as the concurrency token; typed errors (provisional -32010 precondition failed with currentVersion, -32011 not supported; -32602 for not found, matching resources/read). Listing reuses SEP-2640's resources/directory/read unchanged. Search, glob, bulk, and range are deferred.
• docs/decisions.md: 2026-10-09 entry, Status: Proposed.
• python/sdk: prototype on the SDK's Extension/MethodBinding API (no SDK changes), pluggable store plus in-memory store, client helpers, tests including the lost-update case from use-cases.md.
• conformance/: two implementation-independent conflict scenarios.

The proposal lists five gaps in the Python SDK's extension points as feedback for SEP-3371 (no subscription bus access from extension handlers, no metadata on change events, no hook into resources/read, one method across two extensions, legacy wire).

Vocabulary (version, change-set entries) follows Kryspin Ziemski's working document shared in #filesystem-wg.

AI disclosure: drafted with Claude Code; I reviewed the spec and code and ran the tests locally.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	⚠️ Failed 2026-10-14T18:49:30.611565Z	8c05c82	Draft marked ready

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[olaservo]

Thanks Jay for getting this started!

A few comments:

(note: "PS4.4" etc below are referring to the Problem Statements in docs/problem-statements.md.)

1. References to open-questions.md are now out of date. I opened #5 so the skeleton docs link to Daniel's problem statements instead of repeating them. As part of that, open-questions.md now keeps only the three cross-cutting questions (#5 is merged). This PR's "Open questions" section and its decision-log entry still cite the old #1–#6. Could they point at the problem-statement items instead, for example PS5.2 for concurrency?

2. Some problem-statement items aren't covered or deferred yet.

Seems like we still need to cover these:

• PS4.4: marking a URI or subtree read-only, writable, or append-only. Today there's notSupported per URI, and an open question about a server-wide read-only setting, but nothing per subtree and no append-only.
• PS4.5: errors for permission denied and quota exceeded. (Read-only is covered by notSupported.)
• PS5.5: reads pinned to a specific revision.
• PS6.3: subscribing to a directory.
• PS6.4: asks write results to carry ttlMs and cacheScope. "Write results are not cacheable" goes the other way, so it'd help to say why.

For a strawman, I think adding them to the open questions is enough?

3. Should ifMatch be required on delete too? The reason given for requiring it on update ("rules out lost updates by omission", from the decision-log entry) seems to apply to delete as well: an unconditional delete can wipe out someone else's update. Is there a reason to treat the two differently?

4. Smaller spec points

• The Interactions section says servers that track modification time MUST return annotations.lastModified from writes, but the create and update examples leave it out.
• contents.uri MUST equal uri, so it only adds a way to send a mismatch. Could contents drop it?

5. Prototype nits (non-blocking)

• Subdirectory entries from resources/directory/read have no revision in _meta, though the proposal says listing entries carry one.
• Update or delete on a URI outside the store's scheme returns notFound, but create returns notSupported.
• _check_uri requires ://, which rejects urn:-style URIs.
• read_directory returns all entries in one page, with no cursor.

[jayzuccarelli]

Thanks Ola, all of these made it better. Pushed in db67f78:

1. Open questions and the decision-log entry now point at problem-statement items (PS5.2/PS5.4 for concurrency, PS6.x for interactions, and so on), plus the three cross-cutting questions where they still apply.

2. Added PS4.4, PS4.5, PS5.5, PS6.3 and PS6.4 as open questions, each with the current lean. On PS6.4: a write result describes the state right after that write, and another writer can change it at any moment, so the cacheable thing is the next stat or read; the new revision in the write result is what lets a client update its cache safely. Happy to flip that if the group sees it differently.

3. Agreed, no good reason to treat them differently. ifMatch is now required on delete as well as update (spec, decision log, prototype, and a test).

4. Added annotations.lastModified to the create and update examples, and dropped uri from contents; the method's uri names the target.

5. All four prototype nits fixed: listing now says file entries carry a revision and directory entries don't (tied to PS6.3); update and delete on a foreign scheme return notSupported like create; any RFC 3986 scheme is accepted, so urn: works; and resources/directory/read pages with a cursor.

I used AI to help with these changes.

[DanielTemesgen]

Thanks for this!

[DanielTemesgen]

The create and update split gives the same guarantees as one resources/write that requires exactly one of ifMatch or ifNoneMatch: "*", as with HTTP PUT. I have a preference for fewer methods if possible, but this shouldn't block.

[DanielTemesgen]

Prefer sticking with RFC 9457 Problem Details error shapes https://www.rfc-editor.org/info/rfc9457/, but this can be a follow-up.