Re: Is MHTML only for e-mail?

I can see your point about the possibility of proliferating transports
between TCP and MIME, but we need to be careful to rememeber that in
the hourglass model of the Internet, there has to be only one protocol
at each neck.  I propose IP and MIME as two such "necks".

I can speculate that there may be additional such necks above MIME,
but I do not see any more necks between IP and MIME.

I have no concern about proliferating transports like SMTP, FTP, HTTP,
SMXP, et al, between the IP and MIME necks.  These have the effect of
supporting usefully different styles and modes of interworking among
application users, without causing the application information objects
that they work with to become dependent on such verious transports.

But, it is critical to recognize the parallels between necks which
provide tagging and bagging tools to provide "good-enough" typing, and
"datagram" chunking, which at the MIME level allows us to deal with
structured content (which parallels Object Modeling in APIs) and the
IP neck, where datagram chunking allows us to deal with both streaming
content and with user datagrams, among other things.

We also need to remind ourselves to not confuse PROTOCOL with APIs.

Best...\Stef

PS: As MHTML Chair, I wonder if we are getting a bit far off topic,
    though I am vitally interested in these issues.  Is this a topic
    that should be sponsored by some higher level group like the IETF
    APP Directorate?  I think we are really working on an abstract
    model for application support protocol, which as a meta level
    issue does not have a natural home in any of the APP WGs.

>From your message Thu, 09 Oct 1997 09:23:10 +0100:
}
[snip]...[snip]...[snip]...[snip]...
}
}>Perhaps part of what we are recognizing is that there are two classes
}>of "TRANSPORT" protocols.  One just above the IP level that deals with
}>data streams and user datagrams that deal with interoperability, and
}>another class just below MIME that deals with transport of Application
}>Information Objects to provide what I like to call "interworkability".
}
}Why just TWO classes?  Within this expanded idea of a "transport" protocol
}(which I accept) I would suggest that "transport" protocols can be
}identified at several levels within an extended protocol stack.
}
}As new "applications" are constructed and become widely deployed, I would
}hope to see layered architectures within those applications which separate
}issues of control, data transport, information representation, user
}interface, etc.  Hence these new applications would define protocols which
}themselves can be used as a basis for future developments.
}
}I think what you describe is just a step in a continuing evolutionary
}process of building new applications upon the infrastructure of previous
}applications.
}
}GK.
}---
}
}------------
}Graham Klyne
}GK@ACM.ORG

Received on Thursday, 9 October 1997 09:31:03 UTC