Re: Factoring out Content-Disposition (i123)

Frank Ellermann wrote:
> ...
> Indeed, thanks for checking.  IOW Julian's draft did
> not add a new restriction wrt the number of languages
> in a parameter value by limiting it to one piece.
> ...

To be fair, I *thought* I added a restriction, when I wasn't. Thanks 
again to Brian for checking.

In the meantime I'm working on a test suite, which I hope a first 
version of which will be online later this week.

> For your other remark about the length of file names
> in bytes (about 150):  You said this boils down to 17
> code points.   150 / 3 / 17 is about 2.9, so far it's 
> clear.  But the "3" in  150 / 3 is apparently for the
> percent-encoding (?)

Yes. In an UTF-8 octet sequence, any sequence of characters NOT 
representing an ASCII character will have the highest bit set, thus will 
require percent-escaping in a URL.

> A file system supporting Unicode (UTF-8 or UTF-16)
> should be able to store about 50 or 75 code points.

Not sure how you come to that conclusion. For NTFS, the limit depends on 
the API which is used and is either 64 or "unlimited" (I think).

> IMO file name length limits don't belong in 2616bis:

That's true.

But in a draft specific to Content-Disposition we may want to consider 
this. In particular, sending extraordinary long file names (after 
decoding) may be problematic just for the reason of usability in the 
UA's UI.

> <joke> Everybody knows that the limit is 8+3, 8+8,
> 14, 99, 255, or something else in octets for EBCDIC,
> ASCII, OEM, ANSI, UTF-8, UTF-16, or similar. </joke>

I recall a system where it was 8+0 (plus a single 8 character top level 
folder name).

BR, Julian

Received on Tuesday, 19 August 2008 06:30:29 UTC