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

On Feb 25, 2013, at 7:56 AM, Robin Berjon wrote:

> On 24/02/2013 20:20 , Eric J. Bowman wrote:
>> Robin Berjon wrote:
>>> I would support the TAG revisiting the topic of Authoritative
>>> Metadata, but with a view on pointing out that it is an architectural
>>> antipattern. Information that is essential and authoritative about
>>> the processing of a payload should be part of the payload and not
>>> external to it. Anything else is brittle and leads to breakage.
>> 
>> Antipattern?  This *is* the architecture.
> 
> I beg to differ. That's hardly an argument is it? :)
> 
>> Unlike FTP, the HTTP and
>> Gopher protocols introduced the notion of sender intent
> 
> 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.
It allows the sender to have a single resource with multiple representations - allowing the definition of resource identity.

> 
> The trade-offs involved are positive because:
> 
> [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 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.

> 
> Seriously, I have looked, yet I can't find a single piece of justification for the Sender Intent Dogma that doesn't involve hand waving and the same example practically pasted in over and over again.
> 
> I would presume that sender intent, if valuable, would be informative at best.

Yes, it is certainly informative. And a user-agent does its best to represent the wishes of the user. But the wishes of the user are not all that matter (if the user even has relevant wishes prior to seeing the representation). 

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

> 
>> Unlike
>> Gopher, HTTP re-used MIME, avoiding the requirement of versioning the
>> protocol every time a new format (which may have use beyond the Web) is
>> introduced ('h=html' is widely implemented in Gopher, not specc'd).
> 
> Well, given a choice that's certainly a good thing (but entirely orthogonal).
> 
>> Expressed formally, this "late binding of resource to representation" is
>> fundamental to Web architecture; its implementation in HTTP is the
>> Content-Type header.  Without it, there is no mechanism to express
>> sender intent, even one that's somewhat ignored in practice.  I won't
>> equivocate on thinking this to be a good thing...
> 
> 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. 

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"?

> 
>> Given any architecture which supports a variety of data formats, if
>> intermediaries are to be allowed to participate, they can't be required
>> to decode (sniff) the payload to determine the format anyway, without
>> requiring them to have high-end CPUs.  As it is, the Web scales nicely,
>> right down to my decade-old desktop embedded-Linux squid router.
> 
> But intermediaries that do that will be making the wrong decision on a very regular basis.
> 
>> The alternative to Authoritative Metadata, is for the TAG to deprecate
>> sender intent altogether; iow, redefine what Web architecture *is*.
> 
> If the TAG can't redefine Web architecture (in this instance I would say "properly define"), what is it for?
> 
> When you note that a system of rules is broken (and I think that the fact that we need a sniffing document demonstrates that very clearly) you can do one of two things:
> 
> • 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. Changing the rules to prioritize user intent seems to change the very nature of the relationship between a resource, its representations and the creator of that content, when the real problem seems more to do with the relationship between the sender and the user-agent. 

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

JohnK

> 
> Unless you have the means to enforce strong ethical standards, I know of no case in which the former approach actually works.
> 
> -- 
> Robin Berjon - http://berjon.com/ - @robinberjon
>

Received on Monday, 25 February 2013 14:16:44 UTC