Quoteing ned(_dot_)freed(_at_)mrochek(_dot_)com, on Sun, Apr 07, 2002 at
08:44:17AM -0700:
Quoteing ned+ietf-822(_at_)mrochek(_dot_)com, on Sat, Apr 06, 2002 at
06:13:17PM -0800:
I'm pretty confused. These comments don't seem to be on
what I proposed, but I just noticed I mistyped "content-type"
as "application-type" in my example, even though I called it
content type. Maybe that set you off?
Because surely you aren't claiming that people don't actually send zipped
pdfs with a content-type of:
content-type: application/x-zip-compressed
?
This could be considered a violation of 2.2.1, and even a bad idea,
and you could say it doesn't work well, and I would agree with you.
So, you propose that there could be a new CTE, which would be treated as
"binary" by agents which don't know it. It appears to me that an
agent that doesn't understand that CTE will be required to treat it
as "binary". Its not clear to me that this will result in a MUA being
able to do anything with it. Certainly treating it as the advertised
content type won't work, since it would be compressed. I'm also curious
about whether you would suggest two new CTEs, one base64 encoded (for
non 8bit safe transfer, like some SMTP) and one not (for 8bit safe
NNTP tranfer, for example). It just doesn't seem orthogonal to me. But
you like the idea, so I'd like to hear why you don't think these are
problems, if you have time (and you seem to have some :-).
So, I suggested:
content-type: application/x-zip-compressed; encapsulates=application/pdf
It is valid, according to the famous 2.2.1, it will be handled correctly
when passed to whatever is registered as a viewer for that type. It will
also be handled even more correctly if the MUA supports the encapsulates
parameter, and realizes it can be unwrapped and treated as application/pdf.
Sure, I could live with a compressed CTE. I could even live with your
favorite algorithm (hopefully, so can everybody else, or do we need
one CTE per algorithm? yuck.).
Then why are you arguing that it must be done some other way? It is exactly
this sort of thing that leads to nothing being done every time this comes
up -- arguments like this one exhaust everyone so no documents get produced.
I'm not arguing that it MUST be done any particular way, there seem to be two
ways that are syntactically valid, addition of a parameter to content-type,
and definition of a new CTE. One appears to have the advantage of having a
fallback mode to being the same as the current situation, one seems to have a
fallback mode of total non-interoperability. I'm still curious why you
favor a new (or 2 new?) CTEs. If it was so clearly right, it would already
have been done, no?
Good day,
Sam
--
Sam Roberts <sroberts(_at_)uniserve(_dot_)com> (Vivez sans temps mort!)