Re: mustUnderstand, mustIgnore [was: Posted PaceEntryOrder]

[Mark Nottingham <mnot@xxxxxxxx>]

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/