Bill de hÓra writes:
Here’s the thing; almost any mU use-case I can think of involves a point-to-point communication between two parties where the sender is directly addressing the recipient or a relatively small set of recipients. It doesn’t make sense in a pseudo-broadcast environment, which seems to be most RSS served up today. That includes aggregators.
It’s the difference between “I’m sending this document and you must understand these data” and “I’m putting this document on the web and everyone must understand these data”. I doubt the latter is viable.
APP interestingly already has something along the lines of mustUnderstand:
<collection
href="http://example.org/blog/pic">
<atom:title>Pictures</atom:title>
<accept>image/png</accept>
<accept>image/jpeg</accept>
<accept>image/gif</accept>
</collection>
Or from the spec:
A value of “application/atom+xml;type=entry” MAY appear in any app:accept list of media-ranges and indicates that Atom Entry Documents can be POSTed to the Collection. If no app:accept element is present, clients SHOULD treat this as equivalent to an app:accept element with the content “application/atom+xml;type=entry”.
In other words, the sender knows that it can only send one of the listed accepted content types. Which seems to imply that the sender must understand one of those media types - i.e. an atom entry. Which doesn’t seem that far from saying that a client can only send an encrypted atom entry. Or that a client can also send Atom entry drafts
I think there’s probably a valid use case for describing things that a client must do in order to send things to the server. This seems slightly different than Bill’s assertion that mU is only useful inside the message being sent from the sender, which also seems valid.
