At 09:16 AM 5/9/99 -0400, Simon St.Laurent wrote:
At 09:57 AM 5/8/99 -0700, Paul Hoffman / IMC wrote:
>1) You have a MIME-receiving agent (mail agent, HTTP client, etc.). That
>agent knows how to dispatch based on MIME information. It knows how to
>dispatch to programs. These dipatched-to programs might display the content
>directly, or might make a decision and launch a different display program.
>2) You have a generic XML-display program (XMLShow) and some programs for
>displaying particular XML types (DisplayEDI, DisplayCal, and so on).
>3) Someone invents a new XML type (XMLFoo) and a special display program
>(DisplayFoo).
Good examples - except that in all cases, you omit the negotiations phase
where the two ends of the connection can decide whether transmission is
really worthwhile.
Correct. Not all MIME-using mechanisms have content negotiation. Internet
mail, for example. Content-negotiation can and should be dealt with using
content-negotiation protocols. See <http://www.imc.org/ietf-medfree/> for
details.
However, I'd really rather not be downloading material I can't use. If I
know beforehand - from MIME types exchanges in HTTP negotiations, for
instance - that the information is in XML, I may be (depending on my
application type) more willing to take the risk. If not, I'll be spending
a lot of time downloading junk, finding that it doesn't work, and trying to
avoiding getting that type of information the next time around.
Again, this can be handled by using content-negotiation. It would be pretty
easy to add a conneg type that would describe the type of XML that you are
passing, without breaking the example I gave for protocols that don't do
negotiation.
--Paul Hoffman, Director
--Internet Mail Consortium