A client renders tool and prompt icons supplied by servers. A security review notes that one server sends image/svg+xml icons. Which statement reflects the icon rules?
Select an answer to reveal the explanation.
Short Explanation
An SVG looks like a picture, but under the hood it's a document that can hide JavaScript. You're required to handle PNG and JPEG; SVG is a nice-to-have that you handle with gloves on. The trap is treating server-supplied icons as harmless art.
Full Explanation
Icons let servers attach visual identifiers to implementations, tools, prompts and resources. Clients that render icons must support image/png and image/jpeg, and should also support image/svg+xml and image/webp. The specification adds that consumers must treat icon metadata and icon bytes as untrusted, and it warns that payloads may contain executable content, such as SVG with embedded JavaScript; consumers may disallow specific file types or sanitise icon files before rendering, and should validate content against a strict allowlist rather than trusting the declared MIME type. Calling SVG the mandatory format fails because the mandatory pair is PNG and JPEG; SVG support is a SHOULD. Rendering it exactly as delivered also ignores the warning about embedded script. Trusting icons from a server that declared tools fails by concept: capabilities describe features, not trustworthiness, and icon data is untrusted input regardless of source. Saying the specification forbids SVG fails because SVG is explicitly recommended, with precautions; blocking it is a client choice, not a protocol rule. Exam caveat: icon URIs must be https or data URIs, fetched without credentials. Operational check: feed the renderer an SVG containing a script element and confirm the script is stripped or the icon is refused.