Subject: Entry order

From: David Powell <[email-masked]>
Date: Tue, 1 Feb 2005 23:06:34 +0000

Is the order of entries within a feed supposed to be significant? I
can't see anything in the spec. I think we should say something - I'm
guessing that it is not significant, and any ordering should be done
using atom:updated or atom:published.

It looks like this might have got lost accidently when the atom:head
element was introduced. Previously Atom 0.3 said [1]:

> Ordering of the element children of atom:feed element MUST NOT be
> considered significant.

[1] http://www.mnot.net/drafts/draft-nottingham-atom-format-02.html#rfc.section.4

-- 
Dave

---

From: David Powell <[email-masked]>
Date: Thu, 3 Feb 2005 00:18:38 +0000

I think we need to decide one way or the other whether the order of
atom:entry elements is significant, so I've just posted
PaceEntryOrder:

http://www.intertwingly.net/wiki/pie/PaceEntryOrder

== Abstract ==

Specify that the order of atom:entry elements within an Atom Feed
Document is not significant.

== Status ==

Open

Author: DavidPowell

== Rationale ==

Atom 0.3 stated that:

{{{ Ordering of the element children of atom:feed element MUST NOT be
considered significant.  }}}

This text seems to have got lost somewhere during the introduction of
atom:head.  Currently the specification doesn't say whether entries
are ordered or not, which is likely to lead to confusion.

If the specification is not clear about whether processors are
supposed to preserve the order of entries or not, then some
database-based implementations might preserve the order and others
might not.

== Proposal ==

Add the following sentence to Section 4.1 :

{{{ This specification assigns no significance to the order of
atom:entry elements within the feed. Processors MAY present entries in
a different order to which they are appear in an Atom Feed Document.
}}}

-- 
Dave

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 3 Feb 2005 20:25:50 -0800

My preference would be something like

This specification assigns no significance to the order of atom:entry 
elements within an Atom Feed Document. Atom Processors MAY present 
entries in any order, unless a specific ordering is required by an 
extension.

(I.e., I could come up with the UseLexicalOrdering extension, and 
require processors to understand it to use the feed, assuming our 
extensibility model supports that, which I very much hope it will).

Seem reasonable?

On Feb 2, 2005, at 4:18 PM, David Powell wrote:

> This specification assigns no significance to the order of

--
Mark Nottingham     http://www.mnot.net/

---

From: "Bob Wyman" <[email-masked]>
Date: Thu, 3 Feb 2005 23:21:50 -0500

David Powell wrote:
> It looks like this might have got lost accidently when the 
> atom:head element was introduced. Previously Atom 0.3 said [1]:
	+1. 
	The order of entries in an Atom feed should NOT be significant. This
is, I think, a very, very important point to make. 

		bob wyman

---

From: Walter Underwood <[email-masked]>
Date: Fri, 04 Feb 2005 11:27:20 -0800

> is, I think, a very, very important point to make. 

-1

Is this a joke? This is like saying that the order of the entries in my
mailbox is not significant. Note that ordering a mailbox by date is not
the same thing as its native order. 

Feed order is the only way we have to show the publication order of items 
in a feed. I just looked at all my subscriptions, and there is only one
where the order might not be relevant, a security test for RSS readers.
That is clearly not within Atom's charter, so it doesn't count.

wunder
--
Walter Underwood
Principal Architect, Verity

---

From: Tim Bray <[email-masked]>
Date: Fri, 04 Feb 2005 11:44:31 -0800

> the same thing as its native order.

Except for, Atom entries have a *compulsory* <updated> date.  So I have 
no idea what semantics you'd attach to the "natural" order... -Tim

---

From: Julian Reschke <[email-masked]>
Date: Fri, 04 Feb 2005 20:58:13 +0100

> no idea what semantics you'd attach to the "natural" order... -Tim

Nit: they want have an ordering anymore if we allow "updated" dates with 
missing timezone information (i.e., dates with a 24h uncertainty).

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: Walter Underwood <[email-masked]>
Date: Fri, 04 Feb 2005 13:30:27 -0800

--On February 4, 2005 11:44:31 AM -0800 Tim Bray <[email-masked]> wrote:
> Except for, Atom entries have a *compulsory* <updated> date.  So I have no
> idea what semantics you'd attach to the "natural" order... -Tim

Order the publisher wants to present them in. Conventionally, most recently
published first. Entries may be updated without being reordered.

If clients are told to ignore the order, and given only an updated timestamp,
there is no way to show "most recent headlines", which is the primary 
purpose of the whole family of RSS formats.

Right now, you can shuffle the entries and Atom says it is the same feed.

Either we need a published date stamp or we need to honor the order.

wunder

---

From: "Roger B." <[email-masked]>
Date: Fri, 4 Feb 2005 16:28:53 -0600

> there is no way to show "most recent headlines"...

At a single moment within a feedstream, sure... but the next time an
entry is added to that feed, I'll have no problem letting the user
know that this is new stuff.

> Either we need a published date stamp or we need to honor the order.

Maybe I've missed something amidst the chao-- enthusiastic array of
Paces lately, but don't we *have* a published date?

--
Roger Benningfield
JournURL

---

From: Walter Underwood <[email-masked]>
Date: Fri, 04 Feb 2005 15:47:21 -0800

> know that this is new stuff.

But if three are added, you can't order those three. 

wunder

---

From: Graham <[email-masked]>
Date: Sat, 5 Feb 2005 01:14:08 +0000

> a different order to which they are appear in an Atom Feed Document.

First sentence no, but the second sentence says all that we need to say 
and no more.

Graham

---

From: "Roger B." <[email-masked]>
Date: Sat, 5 Feb 2005 01:53:42 -0600

> But if three are added, you can't order those three.

Walter: I dunno... seems to me, if the publisher hasn't included
atom:published info, then it's probably safe to assume that the order
of those entries isn't important.

--
Roger Benningfield
JournURL

---

From: Eric Scheid <[email-masked]>
Date: Sat, 05 Feb 2005 19:20:39 +1100

> First sentence no, but the second sentence says all that we need to say

+1 .. while the spec assigns no significance, a publisher might want to have
more important stories at the front of the feed, albeit knowing full well
that some users will sort things whichever way they want, and some
applications will insist on applying a default sort of their choice.

e.

---

From: Henry Story <[email-masked]>
Date: Sat, 5 Feb 2005 10:57:22 +0100

Having started agreeing with the initial post, and having read more of 
the
thread I am now divided about what the best position is.

In some sense the order is of the entries should not matter. All the 
important
data to order the entries is in the entries themselves given by the 
modified date,
the creation date, ... So if we map a whole feed into an rdf graph 
nothing is
lost. We can use the data in the graph to sort our entries as we wish.

On the other hand an application reading a feed would expect the latest 
entries
to be at the head of the feed. This is very important at the protocol 
level, because
without this guarantee, a client that would like to present the latest 
version
of an entry would be forced to read the whole feed document and all 
feed documents
linked to it, in order to be able to correctly assess that the entry it 
has really is
the latest one.

I think imposing a fixed ordering is not very helpful. Services may pop 
up that
order entries in different ways depending on the interests of the 
receiver. But
perhaps there should be a way to specify what the order of the entries 
is, or
at least give a way to specify that the entries are ordered inverse 
chronlogically
by the modified date when they are. This may be a protocol issue, or it 
may just
be a matter of adding a special info to the feed to specify its 
ordering.

Henry Story
http://bblfish.net/

---

From: Danny Ayers <[email-masked]>
Date: Sat, 5 Feb 2005 14:36:33 +0100

+1.

I accept there are cases where it might be useful to associate
significance to document order, such as 'Top 10' . But I can't think
of any which couldn't be better fulfilled by being explicit within the
entries/feed.

The killer problem of using doc order is that the feed data *will* be
aggregated and republished. Far better to declare the information in
the data (like the date) and let the client (or intermediary) sort
according to the user's requirements.

In a case like Top 10 an extension would be appropriate, link
rel=first/next/previous being one way, RSS 1.0-style feed level
<items><Seq>... being another.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Joe Gregorio <[email-masked]>
Date: Sat, 5 Feb 2005 09:26:29 -0500

> extensibility model supports that, which I very much hope it will).

-1  Atom is a Must Ignore format.

I would prefer:

"""The order of atom:entry elements is typically in reverse 
chronological order, though feeds MAY be constructed
with entries in any order, and this specification assigns 
no significance to the order of atom:entry
elements within an Atom Feed Document."""

There is no reason to even mention how the CLIENT presents the order
of the entries
in this spec.

    -joe

-- 
Joe Gregorio        http://bitworking.org

---

From: Tim Bray <[email-masked]>
Date: Sat, 05 Feb 2005 08:42:12 -0800

> elements within an Atom Feed Document."""

I'm +1 on both Mark and Joe's version, slightly stronger on Joe's 
because I don't think we need drag extensions in.  -Tim

---

From: Tim Bray <[email-masked]>
Date: Sat, 05 Feb 2005 08:40:31 -0800

>>>> Ordering of the element children of atom:feed element MUST NOT be

+1 - I don't care whether we say "MUST NOT", or the other wording 
floating around about "this specification assigns no semantics", but I 
am 100% against assigning any meaning to the order in which things 
appear in the feed.  Every aggregator I've used allows you to sort them 
on any old column, and I totally can't think of a reasonable use-case 
in which preserving the feed order matters. -Tim

---

From: Graham <[email-masked]>
Date: Sat, 5 Feb 2005 16:55:42 +0000

On 5 Feb 2005, at 4:40 pm, Tim Bray wrote:

> I totally can't think of a reasonable use-case in which preserving the 
> feed order matters.

- The Macintouch feed is ordered in the same way as the home page, and 
makes no sense viewed chronologically
- The BBC News feeds have the most important stories first and are much 
more readable and useful with the order preserved.
etc etc

You're shockingly small-minded sometimes Tim.

Graham

---

From: Antone Roundy <[email-masked]>
Date: Sat, 5 Feb 2005 09:59:23 -0700

> because I don't think we need drag extensions in.  -Tim
I like Joe's very much--it reads with perfect clarity and I think it 
says all that needs to be said on the subject.

---

From: Graham <[email-masked]>
Date: Sat, 5 Feb 2005 17:00:57 +0000

On 5 Feb 2005, at 2:26 pm, Joe Gregorio wrote:

How is any of this useful in a normative document?

> chronological order

What does this tell who?

> though feeds MAY be constructed with entries in any order

This is just about useful.

> and this specification assigns no significance to the order of 
> atom:entry
> elements within an Atom Feed Document.

I have no idea what this sentence is meant to tell people. I think 
you're trying to say that nothing can be inferred from the order 
entries appear in, but why you (and apparently several others) choose 
to say it in such a roundabout way is beyond me.

Graham

---

From: Dan Brickley <[email-masked]>
Date: Sat, 5 Feb 2005 11:59:16 -0500

* Tim Bray <[email-masked]> [2005-02-05 08:40-0800]
> appear in the feed. 

+1

Although I could've lived with order being declared meaningful. The 
worst case is when it isn't clear whether ordering info must be 
preserved. Aside: sometimes in RSS1 item order relates to characteristics of the 
things described by the documents in the feed, rather than the docs
directly (eg. job adverts, upcoming movies, ...).

Dan

Dan

---

From: Robert Sayre <[email-masked]>
Date: Sat, 05 Feb 2005 12:13:32 -0500

Tim Bray wrote:

> because I don't think we need drag extensions in. 

"This specification assigns no significance to the order of atom:entry 
elements within an Atom Feed Document. Atom Processors MAY present 
entries in any order, including document order."

Extensions don't get to make demands on generic Atom processors.

Lots feeds will consist of entris with the same date, and lots of 
aggregators will just show things in the order the SAX parser sent it.

Robert Sayre

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 5 Feb 2005 09:48:32 -0800

> -1  Atom is a Must Ignore format.

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.

---

From: Tim Bray <[email-masked]>
Date: Sat, 05 Feb 2005 10:18:18 -0800

> should be used sparingly, but sometimes it's necessary.

Unfortunately my PaceMustUnderstandElement was shouted down by a 
howling mob of WG members with torches and pitchforks.  Sigh. -Tim

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 5 Feb 2005 10:24:17 -0800

Sigh indeed. We have only one chance to do this. This was one of the 
big advantages that I was looking for Atom to have over RSS...

On Feb 5, 2005, at 10:18 AM, Tim Bray 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.
>

---

From: Bill de hÓra <[email-masked]>
Date: Sat, 05 Feb 2005 18:28:19 +0000

> You're shockingly small-minded sometimes Tim.

Rudeness objection.

cheers
Bill

---

From: Tim Bray <[email-masked]>
Date: Sat, 05 Feb 2005 11:51:57 -0800

>> You're shockingly small-minded sometimes Tim.

Hey, I'm used to 8 flames before breakfast from Graham compared to 
which that was a sweet nothing.  He hasn't called me "criminally 
insane" in months and months.  I note that in recent months Graham's 
grownup/childish ratio has been improving markedly, give him a couple 
years and he'll be fine. -Tim

---

From: "Bob Wyman" <[email-masked]>
Date: Sat, 5 Feb 2005 15:38:17 -0500

Danny Ayers wrote:
> The killer problem of using doc order is that the feed data *will*
> be aggregated and republished.
	Precisely! As the blogosphere grows and as the number of feeds grow,
I feel it is inevitable that we are simply going to have to give up the
current "feed-oriented" focus and concentrate more on the entries. Ie: "It's
about the Entries, Stupid!".
	We're seeing the same pattern in "blogs" that we saw with web sites.
In the old days, you maintained a list of known web sites and scanned them
on a regular basis. This was augmented by surfing (i.e. "manual RDF...").
However, today, there is simply too much information and too many sites for
us all to rely on "favorites" lists and bookmarks. Thus, Google has become
the tool for navigating between sites. What we look for today is not "sites"
but rather "pages." While today, the blogosphere is largely focused on the
discussion of "blogs" and "feeds", I feel that in the future, we'll see a
growing focus on entries...
	Web site designers have, in many cases, already begun to learn the
new design disciplines that focus on a page in isolation instead of the
"site-oriented" disciplines that were popular in the 90's and relied on
carefully planned navigation paths through a site. Today's web designer must
recognize that "deep pages" are accessed directly -- not by navigating a
path from the "home page." Similarly, while today's feed developers think
they can rely on presenting an entry within the context of other entries --
which relies on their entire feed being experienced or read, in the future,
feed developers will come to realize that it is NOT their feeds that are
read by people, rather it is the entries that get read. Thus, any
relationship between entries must be contained within the entry -- it can't
rely on position within feed or other contextual clues that require
entry-external data. As Danny says: "Far better to declare the information
in the data (like the date) and let the client (or intermediary) sort
according to the user's requirements."
	To allow document order to be significant compromises the utility of
aggregation and search mechanisms. This should not be tolerated.

		bob wyman

---

From: "Bob Wyman" <[email-masked]>
Date: Sat, 5 Feb 2005 15:49:20 -0500

> You're shockingly small-minded sometimes Tim.
	Do we really need to have this stuff in this forum?

	The Macintouch and BBC News feeds that you provide as examples
simply demonstrate that there is a need for some mechanism to specify order
relationships between entries. The mere fact that in older versions of
syndication formats, document order was the only available mechanism for
hinting at these relationships should not be a compelling reason to avoid
defining more useful and robust order-specification mechanisms.
	Order relationships between entries should be specified *within*
entries, not implied or derived from the context within which those entries
are found. 
"It's about the Entries, Stupid!"

		bob wyman

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sat, 5 Feb 2005 18:01:41 -0800

> 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.

Henrik spent an enormous amount of time devising a
"must understand" feature for HTTP, only to find that the features
needing it were either not worth deploying in the first place
or too risky to deploy even on a "must understand" basis.
The features that people actually needed to deploy were able
to be standardized because those people were willing to work hard
to come to a common agreement on the benefit of the feature.

One problem is that the "must understand" feature is intended to
prevent dumb software from performing an action when it doesn't
know how to do it right. In reality, software tends to have
bugs and developers tend to be optimistic, and thus there is no
way to guarantee the software is going to do it right even
if it claims to know how.  In the end, we just waste a bunch of
cycles on unimplemented features and failed requests.

Another problem is that the features that benefit from a
must-understand bit tend to be socially reprehensible (and thus
the only way they could be deployed is via artificial demand).
As soon as one of those features get deployed, the hackers
come out and turn off the "must understand" bit for that
feature, defeating the protocol in favor of their own view
of what is right on the Internet.

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.

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.

....Roy

---

From: James M Snell <[email-masked]>
Date: Sat, 05 Feb 2005 22:15:52 -0800

My challenge with the idea of mustUnderstand in Atom is in trying to
figure out how the heck it would realistically be used for anything
worthwhile.  Take blog content for instance, if my blog reader accesses
a feed that contains an entry with a mustUnderstand metadata element
that my reader does not understand, does that mean my reader is not
allowed to show me that content?  If so, that's kinda stupid when I can
open the same feed in a browser and view the angle bracket version
without any problem.  In SOAP, mustUnderstand makes sense given that the
messages passed around are generally intended for automated consumption
designed to kick of or affect processes in some way.  Atom feeds are not
typically going to be used that way.  There may be some of that going
on, but nothing that would warrant any intense need to have
mustUnderstand built into the Atom core.  If anything, it could be moved
off into an extension and implemented only by those few who may actually
need it.

- James M Snell

>> should be used sparingly, but sometimes it's necessary.
  ...

---

From: Bill de hÓra <[email-masked]>
Date: Sun, 06 Feb 2005 13:14:25 +0000

James M Snell wrote:
> typically going to be used that way.  

[I don't so much distinction between Atom and SOAP; I suspect Atom and 
SOAP have intersecting uses.]

In my experience  too many people believe their data item is critical 
and thus needs to be non-optional for everyone else. Maybe I don't get 
it, but giving people veto powers over downstream applications strikes 
me as imbalanced, especially for metadata. I have zero confidence in mU 
being used sensibly.

cheers
Bill

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 6 Feb 2005 18:50:35 -0800

On Feb 5, 2005, at 6:01 PM, Roy T.Fielding wrote:

> 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).

---

From: "Bob Wyman" <[email-masked]>
Date: Mon, 7 Feb 2005 03:53:21 -0500

Mark Nottingham wrote:
> some people will undoubtedly ignore the mU flag; that's 
	How should an intermediary like PubSub, Google, Feedster,
Technorati, etc. respond when a mU element is found in an entry? 
	Should it be ignored and the entry forwarded to the subscriber or
included in a search results feed? Or, should all entries with mU elements
be discarded by intermediaries? How can the intermediary know if this is a
reasonable thing to do? Isn't it possible that the mU element might require
something in the feed that is external to the entry that matched the query
filter? Or, is it possible that an mU element could have an effect on the
processing of more than one entry? Thus, if an entry that contained such an
element was inserted into a stream of other entries from other feeds, might
this mU element cause "damage" to the other entries? Should there be two
types of mU? (i.e. intermediary-must-understand and client-must-understand)
If mU is specific to processor type, should we provide a more general method
of specifying who must-understand? If so, what is the extensibility model
for the definition of mU scope?
	More questions can be delivered on demand. In any case, it seems
like there isn't time to finish this discussion.
 
		bob wyman

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 07 Feb 2005 09:41:57 +0000

> Technorati, etc. respond when a mU element is found in an entry? 

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.

cheers
Bill

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 7 Feb 2005 15:22:12 -0800

On Feb 6, 2005, at 6:50 PM, Mark Nottingham wrote:
>> 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.
>

Well, arguably, those same applications should have been tipped
into the waste basket in the first place.  But I don't think you
followed my main point: must understand is a mechanism to enable
fragmentation -- its very presence leads away from standardization.
Lack of mU is one of the reasons that HTTP is not fragmented (along
with me being a stubborn pain in the ass).  Hence, it is only a
problem for some applications that were of questionable character,
and it remains unclear whether HTTP would have benefitted by having
a mU feature or if its presence would have led to a complete meltdown.

>> 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.
>

Right, but look at my examples and try to think of any others that
would require changes in operation on the behalf of recipients.
There may be others, but I am not aware of any more.

>> application except as positive guidance for intermediaries, which is 
>> something that can still be accomplished under mustIgnore with a bit 
>> of old-fashioned advocacy.
>
> 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, 

No, my position is that it isn't necessary to include mU in the format.
Within the control data of an interaction protocol, sure, but not
within the payload of completed actions, wherein any such requirements
are far too late and susceptible to abuse.

Just to be clear that I am not completely against mU in
all protocols, that feature does exist in waka because it is
useful when talking through intermediaries.

....Roy