Re: spec review: ping attribute

Charles McCathieNevile wrote:
> ...
>> Interesting -- good that I asked. It seems we'll not be able to make 
>> progress on this unless we clarify this issue first.
> 
> Indeed. Ian, since you assert there is a problem, could you help us by 
> clarifying what the problem is?
> ...

I would appreciate it if we could continue this discussion over here.

Ian entered a comment over on the associated Mozilla Bugzilla entry -- 
<https://bugzilla.mozilla.org/show_bug.cgi?id=401217#c5>, where he says:

IH> JR> Sorry, but that's a total misunderstanding about what RFC2616 
says about safe
IH> JR> vs unsafe. (related discussion in
IH> JR> http://lists.w3.org/Archives/Public/public-html/2007Oct/0347.html).
IH>
IH> I understand that we disagree on what the spec says here.

So we are agreeing on what we are disagreeing (good). Now let's please 
focus on *that* issue, because the conclusion is essential for how to 
treat the a/@ping issue.

So the scenario is:

1) User A browses web site B.

2) A follows an HTML link to site C.

3) The owner of B wants to be informed of that event in order to charge 
the owner of C for an online ad linking to C.

As far as I understand Ian, he thinks that the notification for step 2 
needs to be done through an unsafe method, because money may be exchanged.

My position is that although money may be exchanged between B and C due 
to the notification (ping), this is a transaction between B and C, and A 
MUST NOT be involved. In other words, following a hyperlink MUST stay 
"safe" in the RFC2616 sense.

Quoting RFC2616, 9.1.1 again:

"Implementors should be aware that the software represents the user in 
their interactions over the Internet, and should be careful to allow the 
user to be aware of any actions they might take which may have an 
unexpected significance to themselves or others.

In particular, the convention has been established that the GET and HEAD 
methods SHOULD NOT have the significance of taking an action other than 
retrieval. These methods ought to be considered "safe". This allows user 
agents to represent other methods, such as POST, PUT and DELETE, in a 
special way, so that the user is made aware of the fact that a possibly 
unsafe action is being requested.

Naturally, it is not possible to ensure that the server does not 
generate side-effects as a result of performing a GET request; in fact, 
some dynamic resources consider that a feature. The important 
distinction here is that the user did not request the side-effects, so 
therefore cannot be held accountable for them."

-- http://tools.ietf.org/html/rfc2616#section-9.1.1

(emphasis on the last paragraph!)

Feedback appreciated,

Julian

PS.: Should someone think that the problem is with what RCF2616 has to 
say, please raise that as an issue over on the HTTPbis WG's mailing list 
(<http://lists.w3.org/Archives/Public/ietf-http-wg/>).

Received on Monday, 29 October 2007 21:25:23 UTC