On Feb 5, 2005, at 6:01 PM, Roy T.Fielding wrote:
On Feb 5, 2005, at 9:48 AM, Mark Nottingham wrote:What does that mean? SOAP is a "Must Ignore format," but it also has a way of saying that you have to understand a particular extension; as I said before, this is one of the big problems with HTTP. mustUnderstand should be used sparingly, but sometimes it's necessary.
The problem with that statement (about HTTP) is that absence of a must-understand in HTTP is not one of its big problems. Yes, I know lots of people have talked about it as a limiting factor in the syntax of HTTP, but to call it an actual problem would say that it prevented some good from being accomplished.
It arguably tipped some people towards SOAP when HTTP would have been adequate. That's not a prevention of good, but we've already seen enough fragmentation in the syndication world.
Things that a syndication format might want to make mandatory are copyright controls and micropayments, but both have been shown in practice to require either a willingness on the part of the recipient to accept that specific restriction (i.e., human intervention and understanding) or forceful requirement by the sender (i.e., encryption). In both cases, agreements have to be established with the user in advance, before they even receive the content, and thus do not need a "must understand" feature.
I don't think mU is intended for such things; rather, the case for mU could be characterised as extensions that change the operation of the protocol in a manner that renders it useless or misleading to try to use the feed if you don't know what to do with the extension. It's advisory.
In fact, "must understand" has no value in a network-based application except as positive guidance for intermediaries, which is something that can still be accomplished under mustIgnore with a bit of old-fashioned advocacy.
So, if I can restate your position, you're saying that you don't dispute that understanding some extensions may be required, but that it isn't necessary to make that visible to the processor, because it'll be co-ordinated beforehand (e.g., through market forces, out-of-band-communication), correct?
I don't disagree that advocacy, standardisation and marketshare have an influence on the adoption of extensions that's impossible to underestimate. mU is not meant to replace this; rather, it's intended to make the introduction of non-compatible extensions a bit easier, by making what the processor needs to support more obvious when it actually sees the feed.
Many people have been saying that mU will be misused, and therefore they don't think it should be included. I don't think this will be the case; it's up to an individual feed author as to whether to use it, and they can easily observe its effects in Atom processors, so they'll be able to make an informed decision as to whether it's necessary. And, as its been said, some people will undoubtedly ignore the mU flag; that's OK too, as long as they know what responsibility they're taking on (i.e., they've opened up the box and have voided the warranty).
-- Mark Nottingham http://www.mnot.net/
