Re: Comments on draft-ietf-httpbis-content-disp

On Mon, Nov 1, 2010 at 5:43 PM, Mark Nottingham <mnot@mnot.net> wrote:
> At a high level, I'd like to use this discussion to resolve issue #186:
>  http://trac.tools.ietf.org/wg/httpbis/trac/ticket/186
> in that once we figure out the depth of error-handling that's appropriate in this spec, we should be able to apply that to the HTTP spec overall.

That's a pretty broad scope, but we can try.

> Some specific thoughts below. Note that I've opened a number of tickets here; please focus follow-up discussion on specific tickets (e.g., calling out the ticket number in the Subject line).

Where you've assigned ticket numbers, I've followed up in separate threads.

> On 01/11/2010, at 7:30 PM, Adam Barth wrote:
>> Jungshik Shin writes:
>>
>> [[
>> As for RFC 5987, I'm aware that it's a profile of RFC 2231 (it's good
>> that it's simpler than the full RFC 2231), but I wrote that it's
>> unnecessarily 'complex' and not many web servers would adopt that
>> anytime soon. That's why I advocated a much simpler approach of using
>> (percent-encoded) UTF-8. I'm aware that it has its own share of
>> issues, but I suspect that it's got a better chance of being adopted
>> by web servers.
>> ]]
>>
>> I agree with his assessment.  We should simply use percent-encoded
>> UTF-8 instead of letting the server specify whatever crazy encoding it
>> dreams up.
>
> The 'crazy encoding' you refer to isn't dreamed up by the Web server. Regardless, if you'd like to pursue this path, you need to make a proposal and do the legwork to show that implementers will support it, with a reasonable backwards-compatibility story.

Has Julian done the legwork to show that implementers will support his
draft?  All the bugs I've seen that he's filed with Chrome seem to end
up with Jungshik Shin refusing to implement his proposal.

>> Also, we should remove the language tagging facility
>> because it is gratuitous.
>
> Can you say a bit more here? We can open an issue for this, but your reasoning (beyond "it's gratuitous") isn't clear.

Put another way: what's the use case for including a language tag?

>> In short, this document does not address the needs of browser user
>> agent implementors.  This objection can be resolved in two ways:
>
> This isn't the W3C, we don't have objections. Make arguments and they'll be judged on technical merit, based upon the rough consensus of implementers and their running code.

Feel free to read the word "objection" in the usual english sense and
not in the technical W3C sense.

All the issues I've raised in my email are based on code that's been
running for over a decade.

Adam

Received on Tuesday, 2 November 2010 03:10:09 UTC