Re: Feedback on the ping="" attribute (ISSUE-1)

Well said Roy!

The more I see these discussions, the more I remain convinced
that the HTML5 exercise should limit itself to what it originally
claimed it was doing, namely documenting the actual behavior of HTML4.

Roy T. Fielding writes:
 > 
 > On Nov 6, 2007, at 2:11 PM, Ian Hickson wrote:
 > > On Tue, 6 Nov 2007, Mark Baker wrote:
 > >> On 11/6/07, Ian Hickson <ian@hixie.ch> wrote:
 > >>> On Tue, 6 Nov 2007, Mark Baker wrote:
 > >>>>>
 > >>>>> In that case I don't understand what we are discussing. Could you
 > >>>>> define the terms in more detail?
 > >>>>
 > >>>> Are there any specific terms you had in mind?  I think we all  
 > >>>> understand
 > >>>> what "safe" means.
 > >>>
 > >>> I don't think I do, since the way you are using it doesn't match  
 > >>> what I
 > >>> understand of the term.
 > >>
 > >> Ok.  The closest thing to a definition that Roy's cited, AFAIK,  
 > >> can be
 > >> found here;
 > >>
 > >> http://lists.w3.org/Archives/Public/www-tag/2002Apr/0207.html
 > >>
 > >> But again, the word can be used in many contexts, including both the
 > >> contexts that are of importance here: message and implementation.  So
 > >> I'm not sure that will help.
 > >
 > > The above e-mail seems to imply that a message in HTTP is "safe" if it
 > > causes no loss of property for the user (with a loose definition of
 > > property here).
 > >
 > > By that definition, any method would be safe for the purposes of
 > > processing ping="", because the semantics of the message are simply  
 > > that
 > > the user agent is notifying the server of an action.
 > >
 > > Note, though, that it seems that the danger is not in doing "safe"  
 > > things
 > > with "unsafe" methods, but with doing "unsafe" things with "safe"  
 > > methods.
 > > That is, doing "unsafe" work (work which can cause loss of  
 > > property) is
 > > bad when you're using GET or HEAD -- but doing "safe" work as part  
 > > of a
 > > message with "POST" is harmless. As far as I can tell.
 > >
 > > On the other hand, if we agree that "idempotent" means "has no  
 > > important
 > > side-effects" (for anyone), then clearly ping="" is not idempotent,  
 > > and
 > > so we have to have a non-idempotent method.
 > >
 > > Does that make sense?
 > 
 > Not really.  The actions generated by a user agent should be consistent
 > with the actions selected by the user.  That is why TimBL had an axiom
 > about GET being safe -- clicking on a link (or a spider wandering
 > around) must be translated into a safe network action because to do
 > otherwise would require every user to know the purpose of every
 > resource before the GET.  It follows, therefore, that the UI for a
 > user action that is safe (a link) must be rendered differently from
 > all other actions that might be unsafe.
 > 
 > In short, if the UI is being presented as a normal link, then the
 > HTTP methods resulting from the user's selection must all be safe
 > (GET/HEAD/OPTIONS).  You can argue this one for the next few years
 > if you like, but I'd be shocked if the TAG let anything else
 > progress past the WD stage.
 > 
 > I don't care how many user agents already get it wrong today. They
 > are responsible for their own implementations.  We are responsible
 > for the standards by which those implementations will be judged
 > broken and liable for that broken behavior.
 > 
 > The discussion on ping assumes that the ping target is expecting
 > to receive empty-body POST requests (i.e., that the target has
 > not been deliberately supplied to fool an unsuspecting user into
 > triggering a non-safe action when they select the link).  But that
 > is an invalid assumption -- the target of the ping could be any
 > URI, including those that do fun things like delete wiki pages
 > or print documents or send mail ... we've been through this all
 > before and not all of them require bodies.  That's why HTTP and
 > HTML both have requirements on use of safe methods.
 > 
 > In any case, I still see no reason for this attribute to exist.
 > I am well aware of how link tracking works and the entire
 > history of the user tracking industry in Web protocols (due to
 > a recent patent case), and you haven't even reached the most
 > minimal requirements that a real site would need for tracking
 > referrals, and would never be capable of proving undercounts
 > [the sole apparent reason for this new feature] because there
 > is no guarantee that the two DNS requests will deliver equally
 > reachable servers for the ping and href, nor that the href
 > request will succeed before the ping succeeds, nor that the
 > href URI corresponds to the ping-per-referral URI.  It is for
 > all of those reasons that people use redirects, referer, and
 > cookies today and those will never be solved by ping.
 > 
 > A solution to that problem, if one exists, needs to be vetted
 > by people at companies that do referral tracking and payments in
 > real life, not as a hacking exercise in cool features, and for
 > that you will need to talk directly to the right people at
 > Google, Amazon, Linkshare, and at least a few of the retailers
 > that are aware of all the ways in which tracking can be abused.
 > 
 > Even if such a ping was standardized, it would be years
 > before a sufficient number of deployed browsers were out there
 > to make it work, and during that time the content providers
 > would have to do both redirects and pings to get their numbers.
 > It is, from all perspectives, just a bad idea and not ready
 > for anything that calls itself an HTML standard.
 > 
 > ....Roy

-- 
Best Regards,
--raman

Title:  Research Scientist      
Email:  raman@google.com
WWW:    http://emacspeak.sf.net/raman/
Google: tv+raman 
GTalk:  raman@google.com, tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc

Received on Thursday, 8 November 2007 13:55:50 UTC