Re: a/@ping discussion (ISSUE-1 and ISSUE-2), was: An HTML language specification vs. a browser specification

On Thu, 27 Nov 2008, Julian Reschke wrote:
> 
> I personally think the text is good enough as a starting proposal. I 
> would recommend to put it into something reasonably self-contained, such 
> as a separate doc, an appendix or a subsection (preference in this 
> order).

A separate doc seems best. Please feel free to take the text and modify it 
as you wish to; let me know when there's something to point to and I'll 
update the spec accordingly.


On Thu, 27 Nov 2008, Julian Reschke wrote:
> > 
> > <a onmousedown="return clk(this.href,'','','res','1','')" class="l"
> > href="http://example.com/foo">example.com/foo</a>
> 
> Evil.

Yeah, that's why we want to change this.


On Thu, 27 Nov 2008, Julian Reschke wrote:
> >
> > I agree that feedback should be public. However, I'm not going to 
> > ignore private feedback. ...
> 
> Is there any reason why you can't forward this feedback in some kind of 
> anonymized form?

I have relayed all the points that were made that I can mention publicly 
in the e-mails I have sent in the past few weeks.


> > It makes it less likely that the link will be followed by people who 
> > don't realise it's a ping. For example, a tool that scans an HTML file 
> > for URLs and fetches them all to check for broken links would cause 
> > problems if we used GET or HEAD, but would be fine if we had a 
> > different method.
> 
> That tools wouldn't send the payload specified in the spec, so how would 
> that matter?

Defence in depth, for the cases where pings are stored without checking 
the payload. (In many cases, the actual ping URL will contain all the 
information that the auditor needs, so the payload is not always 
necessary, and so might be ignored as an optimisation.)


> > > I think that using POST *can* produce new security problems, while 
> > > GET/HEAD wouldn't,
> > 
> > Could you describe the new security problem? So far all you have 
> > described are problems that already exist with forms.
> 
> It follows from the fact that POST can have write semantics while 
> HEAD/GET doesn't.

Could you show us a series of steps that shows an actual new security 
problem? Claiming there is the possibility of a new security problem 
without any actual problem to show is basically scare mongering.


> > So in summary: 
> > * You don't agree that the solution as specified will be reliable enough
> > so that it actually gets used - other feedback claims otherwise.
> 
> Feedback you haven't shown us. Also, contrary to feedback from others.

I have stated that Google wants to use this mechanism once it is widely 
deployed. There's at least one e-mail in the WHATWG archives from someone 
else announcing intent to use this feature. What feedback do you want me 
to show you?


> > * You are concerned that UAs may implement the protocol part and 
> > neglect the UI part - implementators have specifically avoided doing 
> > this.
> 
> FF3 almost shipped with it without UI support; which I think is evidence 
> that there's a danger.

I don't think anyone is saying there's no danger of bugs.


> > * You think that using POST *can* produce new security problems, while 
> > GET/HEAD wouldn't - but haven't described these problems.
> 
> My concern is based on the semantics on POST, which is a big enough 
> reason for me.

I understand that, but I have to balance your feedback with everyone 
else's.


> > * You think that GET/HEAD would just work fine - other feedback claims 
> > otherwise.
> 
> Again: feedback you aren't showing us.

I've enumerated the points I can publish from this feedback.


> > * You believe that issuing an unsafe HTTP request in the context of 
> > page navigation is in conflict with the web architecture - but are not 
> > willing to do the work to get a more suitable method that doesn't 
> > conflict with other feedback we've received, and our design principles 
> > say I must put practical implementation concerns above spec purity.
> 
> "These design principles are an attempt to capture consensus on design 
> approach. They are pragmatic rules of thumb that must be balanced 
> against each other, not absolutes. They are similar in spirit to the 
> TAG's findings in Architecture of the World Wide Web, but specific to 
> the deliverables of this group."

Indeed.


> > * You think the Ping-To and Ping-From headers should be in the body of 
> > the ping because that's what the payload is for, and it avoids 
> > polluting the header registry with headers that are tied to a single 
> > specific use case - but other feedback has said that there are 
> > implementation reasons to prefer headers, and our design principles 
> > say I must put practical implementation concerns above spec purity.
> 
> Again, this is the "whatever hack gets us there, no matter what the base 
> specs say" approach.
> 
> I really think we need to have an iteration on the discussion of design 
> principles.

I agree; I really would like the "baby steps" principle that I proposed 
long ago to be added, for instance.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 27 November 2008 21:53:12 UTC