- From: T.V Raman <raman@google.com>
- Date: Thu, 8 Nov 2007 05:54:55 -0800
- To: fielding@gbiv.com
- Cc: ian@hixie.ch, distobj@acm.org, julian.reschke@gmx.de, public-html@w3.org
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