Before JSON Patch (RFC 6902) became fashionable, there was XML Patch — a tiny, elegant spec that lets you describe a partial update to an XML document as a small XML document of its own. RFC 5261 defines the application/xml-patch+xml media type and a three-verb vocabulary: <add>, <replace>, and <remove>. Each operation carries an XPath sel attribute that points at exactly the node — element, attribute, or text — you want to change.

The problem it solves. By the mid-2000s, systems like SIP presence (SIMPLE), XCAP resource lists, and the Open Mobile Alliance's XDM were pushing sizable XML documents over the wire. A phone with a 500-entry buddy list did not want to PUT the whole list every time a contact was added. HTTP's PATCH verb (RFC 5789) existed, but PATCH is just a transport — you still need a diff format. RFC 5261 filled that hole for the XML world.

Key design decisions.

• XPath as the selector, not line numbers or byte offsets. This means a patch survives whitespace changes, attribute reordering, and namespace prefix rewrites. It's the semantic sibling of JSON Pointer, but far more expressive.
• Only three verbs. The authors deliberately rejected a rich transactional grammar. Anything harder than add/replace/remove is what full document replacement is for.
• The selector must match exactly one node. Ambiguity is an error, not a "best effort." This makes patches idempotent-ish and easy to reason about, at the cost of forcing the client to know the tree.
• Whitespace nodes are addressable. A subtle but hard-won choice — because XML treats text between elements as real nodes, a naive implementation that ignored them would silently corrupt mixed-content documents. The RFC has an entire section on this trap.
• Namespace context lives on the patch operation itself. You declare prefixes on the <add> or <replace> element and they bind to the XPath expression. This avoids the "which prefix does ns:foo mean?" ambiguity that plagued earlier proposals.

An example. To add a phone number to a contact and delete an old email:

<d:patch xmlns:d="urn:ietf:params:xml:ns:patch-ops">
  <d:add sel="/contacts/contact[@id='42']" type="@phone">+1-555-0100</d:add>
  <d:remove sel="/contacts/contact[@id='42']/email[1]"/>
</d:patch>

Note the type="@phone" syntax: when adding an attribute rather than an element, you name the attribute in the type. It's a slightly awkward affordance that reveals XML's dual data model (elements vs attributes) leaking into the patch grammar.

Why it still matters. XML Patch is the workhorse behind XCAP (RFC 4825), which in turn powers presence, buddy lists, and conference state in every IMS deployment on Earth — meaning if your carrier's VoLTE stack tracks who's online, RFC 5261 is quietly involved. It also shows up in 3GPP specs for MBMS service announcements and in some NETCONF-adjacent tooling. And it's a case study in restraint: JSON Patch borrowed the "small verb set + pointer selector" pattern almost verbatim four years later, while adding test and move. Whether those additions were wisdom or scope creep is a fine dinner-party debate.

Historical curiosity. Jari Urpalainen was at Nokia when he wrote this; the spec came out of a real production need for Nokia's SIP presence servers, not an abstract standardization exercise. That's why it feels engineered rather than architected.