Re: TRACK, was: LC comments.

On Fri, 13 Jun 2008, Julian Reschke wrote:

>> Or they have implemented something completely unrelated in their server 
>> that just happens to be called TRACE and are confused why they can't 
>> interact with it using XMLHttpRequest.
>
> Which would mean that a non-normative appendix telling the story about the 
> risk related to TRACE (and TRACK) would be helpful.

+1

>> That line of reasoning would mean that we shouldn't put any security 
>> restrictions in the spec and then just tell UAs to deal. There are several 
>> downsides with that:
>> 
>> 1. Users would get annoyed when running into the restrictions that don't
>>    show up in the spec.
>
> Like PROPFIND not working (IE7), or silently rewritten to "GET" or "POST" 
> (Opera)?
>
> Yes, I do agree that explaining this is useful, I just don't see why it's 
> necessary to make it a normative requirement, and put it into the API 
> documentation.
>
> An appendix would be completely sufficient.

This is just another proof that the spec should have two section, one 
designed for authors, and one for implementation considerations.

I would add that it is entirely possible to reorganize the spec, even 
after CR if no normative changes are done. Making the spec more clear as a 
result of editorial work will vastly improve its quality, and ensure that 
targeted parties will find what they need easily, and not relying on their 
hands-on experience with different browser because the spec might be 
opaque to some.
Cheers,


-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

Received on Friday, 13 June 2008 19:23:03 UTC