While I am supportive of the need for an object security proposal, I do
want to observe that the IETF has not officially endorsed an object
framework. MIME is certainly a contender but it has never been formally
sanctioned in that way.
Insofar as MIME is the object framework of choice, Security Multiparts
is the object security framework of choice. That leaves choosing the
security protocol itself, be it S/MIME or OpenPGP. Frankly, that's a
debate we don't need and I hope we don't have.
My worst fear is that the recently proposed "mailcap" will go there.
I'd prefer we just have a way of knowing which protocol is supported by
a recipient and let it go at that. We've already seen how well the
market and our process handles choosing secure email protocols.
So, I don't think this working group should include this action item.
Jim
--
James M. Galvin Director, EC Technologies
CommerceNet Consortium +1 410.549.5545
http://www.commerce.net +1 410.549.5546 FAX
All the world's a stage and most of us are desperately unrehearsed.
-- Sean O'Casey

attached mail follows:

At 09:31 28/01/99 -0800, Chris Newman wrote:
>I'm interested in feedback on the following BOF/WG idea. Do you think
>this is a good/bad idea? Any suggestions to improve the proposed charter?
>Anyone interested in being a document editor of either of the two
>proposed documents or interested in WG chair/co-chair position?
>
> - Chris
>------
>The APPLCORE BOF will discuss the following proposed charter:
>
>Application core protocol WG (APPLCORE)
>
>The IETF has traditionally developed application protocols directly on top
>of a raw TCP stream. However, there is a growing set of problems which
>many application protocols have to solve regardless of what the protocols
>do. This WG will identify these problems, identify the successes and
>failures that deployed IETF protocols made when addressing these problems
>and design a simple core protocol to address these problems. This core
>protocol may then be used by future application protocols to simplify both
>the process of protocol design and the complexity of implementing
>multi-protocol servers.
While I applaud the general intent, I echo other concerns that the goal is
too ambitious.
Specifically, I find the idea that we can "design a simple core protocol to
address these problems" is something of a tall order. What I do think may
be achievable is to identify a range of problems, and then make
recommendations about solutions to these.
Your reference a number of areas that may be considered:
> * connection user authentication and privacy (e.g., SASL and STARTTLS)
> * server capability/extension announcement (e.g., SMTP EHLO)
> * extensible command/response syntax and structure
> * error status tokens and human readable error text issues
> * syntax for transfer of large (multi-line) objects (e.g., dot-stuffing,
> length counting, chunking)
> * multiple commands in progress at the same time (command ids or tags)
> * unsolicited server messages
> * command pipelining (sending multiple commands without waiting for
> responses)
> * Structured data representation (e.g., RFC 822-style AV pairs, IMAP
> s-expressions, LDAP ASN.1, XDR, etc) in command/response syntax.
> * low bandwidth support (e.g., compression layer or packed binary
> protocol encoding)
> * connection shutdown (QUIT/LOGOUT command)
I would add object security (e.g. S/MIME, openPGP),
For each of these there may be one or more preferred solutions. I think
the detailed specification of technical solutions should be separated from
a document that makes recommendations about how these may be effectively
used together to create new application protocol.
To the maximum extent possible, existing protocols should be used. With
few exceptions, what remains is, I think, a statement of how these are
combined to create a new application protocol.
So, instead of "core protocol", how about "core protocols"?
#g
------------
Graham Klyne
(GK@ACM.ORG)