Re: Revisiting Authoritative Metadata (was: The failure of Appendix C as a transition technique)

Hi John,

On 25/02/2013 15:16 , John Kemp wrote:
> On Feb 25, 2013, at 7:56 AM, Robin Berjon wrote:
>> Which is good because:
>>
>> [list use cases here]
>
> It allows the sender to provide a hint about how the resource should
> be interpreted (rendered) by the user-agent.

Ah, but a hint is not what we're discussing here. We're talking about 
*authoritative* metadata. If the sender said "I reckon the most useful 
way to look at this is such and such" then that's certainly useful.

Note that I'm not advocating that we remove content type. Even if we 
wanted to, it wouldn't be possible. I'm merely pointing out the fact 
that it shouldn't be raised to the level of an architectural feature 
because it leads inevitably to broken behaviour.

Put differently: we can't get rid of it, but we can at least note that 
it would be best if new contributions to the ecosystem didn't rely on it.

> It allows the sender to
> have a single resource with multiple representations - allowing the
> definition of resource identity.

But for that you don't need content typing in the headers. Content 
typing as part of the payload works perfectly fine for such purposes 
(better, in fact, since it makes discrepancy much harder).

>> [discussion of why sender-intent is good]
>
> I don't presume to decide whether sender-intent (or anything else) is
> "good" or "bad", but it has the properties described above. I think
> those properties are useful

But as I point out above, the properties you list are either not 
required for the cases you cite, or not authoritative.

> because I think it would be very
> difficult for a user (or a user-agent) to determine (divine) whether
> the sender meant this resource to appear as a text/plain document for
> their purposes, or as HTML, unless the architecture had a way for a
> sender to indicate its intentions.

Again, I would like to see an example that doesn't involve the 
text/plain vs text/html distinction.

>> I would presume that sender intent, if valuable, would be
>> informative at best.
>
> Yes, it is certainly informative.

But that's not what the architecture is claimed to be.

>> User intent trumps all.
>
> How can the user intend something about which they have no prior
> knowledge? The sender says "this representation should be treated
> this way" - the user can ask for another representation.

The fact is that user agents will routinely disregard such sender 
messages because they are wrong (and interpreting them as if they were 
right is detrimental to the user).

>> Again, we give such prominence to sender intent, despite obvious
>> wide-scale deployment issues, because [blank].
>
> I think some prominence should be given to sender intent because the
> sender is in a better position to know about the content being
> delivered than the user is. However, senders are often not
> intentional either.

And regularly wrong.

> What's wrong is that many senders are incorrectly configured in such
> a way that they say "I say this resource should be represented as X"
> when it is actually Y, because they don't actually know.
>
> What if they were, by default, configured to say "I don't know what
> this representation is"?

That's where I think we should be headed. Media types should only be 
used when there is known ambiguity. Other than that, we are better off 
without them. And new formats should be designed in such a way that they 
don't require media typing metadata.

>> • Ask that people "behave better" and go against their best
>> interest (this works, why bother fixing it?). • Fix the rules.
>
> I don't think that the rules are broken just because people violate
> the rules.

No, that would not be sufficient. But the situation we have contains a 
stronger condition: senders break the rules by mistake, which causes 
receivers to *have* to violate the rules.

Rules that make the most desirable option be routine violation of the 
rules are broken rules.

In the absence of a Web Police we have to build rules that contain 
within themselves the incentives to be followed. Anything else is doomed 
to fail. I guess that's an undocumented architectural principle :)

> If default behaviour were that a sender could (and did) say "I don't
> know", would this improve the situation?

It would, and it's more or less the assumption atop of which I believe 
we should build.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Received on Monday, 25 February 2013 14:37:17 UTC