Re: Content-Disposition next steps

On 21.12.2010 01:27, Jungshik Shin (신정식, 申政湜) wrote:
> Hi,
>
> As I wrote below, I really appreciate Julian and Adam for working on
> this long-standing issue at long last.  I should have joined the effort
> much sooner. Anyway, whether it's a single RFC or two RFCs (one on
> standard-track and the other being informational), I'm with Adam that
> it'd better reflect the 'reality' of what web servers do in the wild.
> ...

Well, one goal of writing a spec (in particular at "proposed standard") 
is to define a good way to do things.

Of course, documenting what's out there today is *also* useful. However, 
as my many tests show, there is currently no interoperability at all (at 
least for I18N), so I'm not sure what you're proposing beyond the fact 
that things are messed up (essentially giving instructions to do UA 
sniffing).

> ...
> I found a few other Google products emit RFC 2047 for Firefox and
> Chrome. As for Opera,  I must have been hallucinating !  I can almost
> swear that I saw a change go in to make gmail  emit RFC 2231 (it's
> before RFC 5987) for Opera, but it turned out that it's not the case,
> yet. I'm sorry for the incorrect statement in the previous email.  On
> the other hand,  I found that Google Sites emits 'RFC 2231'  for
> Firefox, but not for Opera (let alone other browsers).
> ...

At this point, servers can emit RFC2231 encoding for all browsers except 
IE, Safari, and Chrome (which will change with Chrome 9, right). I think 
this should be considered the best way to do it; it special-cases only 
those browsers who haven't implemented the recommended way of doing 
things yet.

> BTW, Google search turned up a 7-yr old  mail thread at
> www-international (
> http://blog.gmane.org/gmane.org.w3c.internationalization.general/month=20031101 )
> where I did advocate for RFC 2231 :-) but others (out of 'practical'
> needs/concerns) recommended using RFC 2047. It's old and I have little
> idea how wide-spread the practice is now, but it's an indication that
> using RFC 2047 (used to) has (have) some following. That may have been
> partly due to HTML4's and RFC 2388's references to RFC 2047 (2045)
> although they're about uploading a file as a part of multipart-form data.

Well, the only UA supporting RFC 2047 up until two years ago was 
Firefox, and at that point Firefox implemented RFC 2231 as well. So it's 
strange that we apparently have legacy servers actually *using* this.

It shows that the clarification re RFC 2047, both in the base specs and 
in the C-D spec are really needed.

> Anyway, this issue should have been escalated a long long ago and I very
> much appreciate Julian's and Adam's efforts to nail this down.
>
> As for what's actually being emitted by web servers, my guess is that
> raw byte sequences in various encodings (including UTF-8) are most
> common followed by simple %-encoding (again in various encodings), which
> is in turn followed by RFC 2047 (depending on UA web servers talk to)
> with RFC 5987 emitted by a small number of servers.

I don't think it's true, but I can't prove it. Back when I researched 
this many years ago, the recommendation was to server %xx to IE, and 
sent RFC 2231 to everybody else (where everybody else back then 
essentially meant Firefox and Opera).

> I wish I had some cycles to collect stats for C-D headers (over
> 'attachments' Google crawled). I'll ask around if anybody has done that
> (when I did a year or so ago, I couldn't find any). However,  I'm
> afraid  just tallying C-D headers of 'attachments' that were already
> crawled (e.g. Google corpora) wouldn't work.  I guess we need to crawl a
> good/representative sample of web sites again "masqurading as Firefox
> (or other browsers)" because most web sites (that emit RFC 2047) are
> likely to do that only for Firefox (and in some cases, Chrome).
>
> As an alternative to the above, I wonder if browsers can collect some
> stats on the format of C-D header.

That would be great.

So. How do we proceed now? Mark?

Best regards, Julian

Received on Tuesday, 21 December 2010 10:06:35 UTC