As Martijn says, ``content-type'' should not be a special keyword in the
anchor because it's not an attribute of the link. If the protocol *can't*
type the data then the URL should allow some place to define this. E.g.:
<A HREF="ftp://host/file.tar.Z;{content-type=application/x-tarZ};">
Simply stated, protocol dependent parts should go in the URL space.
A ***BIG*** problem with the URL space right now is that it's not
extensible!!!! So we can't add this without breaking things somewhat.
That issue really needs to be addressed.
The only solutions that I can see are to make it heuristic and define a
syntax that isn't likely to break any existing URLs, or add new protocol
types. Either way, all browsers would have to be updated before we could
start using the new syntax but the sooner the better I would say.
Geez, what a mess.
So if we use something like ``;{...};'' that isn't likely to appear
in current URLs then we can remain 99.9% backwards compatible.
ftp://host/path/file;{attr=value,value;attr=value};
New protocol types using attr/value pairs might look something like:
anon-ftp:h=hostname:p=port:p=/pub/README:content-type=application/x-tarZ
BTW: (need I say it?) *IF* we go with something like the above the HTTP
request format would NOT change. The additional information would go in
the headers somewhere.
--sanders