Re: New SCMP Discussion List

At 12:51 30/06/99 -0500, Gunther Schadow wrote:
>I wrote:
>>Now my wining.  I think that the emerge of this SCMP draft is a sign
>>of a bad coordination that goes on in the IETF.
[...]

Much of your complaint seems to be based on the premise that there should
be only one of any kind of standard-track protocol.  While I accept that
wanton proliferation is undesirable, I don't accept that "only-one" is a
principle of dominant importance.  I have heard it said that the "IETF way"
is to allow multiple protocols to go forward and "let the market decide",
as long as the underlying Internet infrasructure and architecture is not
threatened.  We do have both S/MIME and PGP on the standards track.

>In the rest of this I am commenting on Graham Klynes remarks
>
>> I am just an interested party, and not a principal in the SCMP
>> proposal, but I would like to toss in a couple of reasons why I find
>> SCMP useful in ways that EDIINT is not:
>
>This is precisely what I'd like to see very clearly presented in a
>comparison. What exactly is the difference between the SCMP approach
>and the EDIINT approach, what the benefit of SCMP, what the deficiency
>of EDIINT.

My answer:  I read the SCMP specification and I understood it.  I read the
EDIINT specifications, and I did not have full understanding of what was
being proposed.

Under such circumstances, I think that it behoves the EDIINT members to
offer such a comparison if they believe that SCMP is damaging to their
interests.

I posted my concerns about the EDIINT drafts to the mailing list, and the
only response I got was to the effect of "we think it's all right for our
purposes".  That's fine by me, but it's no way to get wider buy-in.

>> (a) SCMP is quite specific that it is intended to be payload- and
>> service- neutral.
>
>This sentence is a contradiction in itself. "X-neutrality" is a
>quality that people claim for their work and X-neutrality is often
>taken synonymous with "open."  But if you look more closely,
>X-neutrality means that you don't standardize with respect to X.

This is pointless logic-chopping, but since you attack, I'll defend my
words:  the word "specific" was in reference to the intent of SCMP;  the
word "neutral" was in reference to the SCMP payload.

>So, a standard that has options must be very clear on how the
>optionality is managed.

On this I agree, and this is an area that I would like to see addressed in
a revision of SCMP that may be offered for standards track.  I am on record
on the SCMP list with comments to this effect.

><Error number> is another such example of things that are simply left
>blank and up to the implementer. Nice, but not interoperable.
>
>I just don't see the big advantage about SCMP.

I gave one above, namely that I found it easy to understand the specification.

But another is more subtle.  To my mind it is clear that SCMP is not a
complete protocol in itself, but a protocol element that may be combined
with other elements (security multiparts, S/MIME, SMTP, HTTP, etc, etc).
Therefore it allows an application designer some freedom to build the
functionality that they may require.  Thus, it can form a basis for a
family of application protocols that have a common requirement for
non-repudiable message transfer, rather than trying to fit everything into
a single monolithic whole.

To my mind, SCMP looks rather like TCP/IP to EDIINT's SNA.

>> I think future developments of this specification might form a
>> useful basis for a range of applications that require non-repudiable
>> message delivery over a variety of message transports.
>
>No, no, not SCMP in the future will be a useful basis, but MIME *is*
>such a useful basis already today.

Why do you imply these statements are mutually exclusive?  I think BOTH are
useful.  MIME cannot offer non repudiation.

>Going for SCMP to be everything for everyone, 
[...]
I never said that.  Just that I see SCMP as a useful building block for
more than a single application.

>[...] Sure, you can send personal messages through SCMP, sure you
>can deliver cooking recipees through SCMP, but so what? All that I can
>already do with simple and standard MIME using Netscape mail or your
>favorite commercial or free mail user agent.

Again, you are distorting what I said.  Your comment ignores the niggling
little detail of non-repudiation, concerning which I was very clear.

[...]
>> I think that the simplicity and directness of the SCMP specification
>> is in the spirit of other classical and succesful IETF protocols.
>
>I disagree for reasons shown above. If you can read an understand the
>"classical" Internet specs IP, TCP, UDP, TELNET, RFC and FTP, RFC822,
>and SMTP, you should be able to read and understand MIME, RFC1767, and
>EDIINT REQ, AS#1, and AS#2 easily.

This is clearly a matter of opinion.  I found the EDI drafts excessively
repetitive and difficult to separate out the aspects of interest to me.  I
don't want to do EDI (in the sense that I understand EDI).  I want a
framework for non-repudiated message exchange, which can be used with MIME,
RFC1847+S/MIME, different (arbitrary) message transfer mechanisms, etc.

Now maybe EDIINT can do this, but it wasn't clear to me.  On the other
hand, I could see a large part of the framework I sought in SCMP.  If you
think that EDIINT would fit the bill, I think you'd do better to try and
explain why, rather than complain about a different proposal.  And I do say
that the quality of the documents is as important, if not more important,
than the quality of the underlying engineering.  To parrot a management
maxim: "Perception is everything".

To echo Jason's comment in another message:  I would be happy to
participate in a group get-together in Oslo to try and better understand
the similarities and differences in these protocols.

BTW, since I have your attention.  You mentioned that EDIINT "uses standard
message disposition notifications".  When I read the EDIINT documents, I
noted that they appear to violate one of the fundamental restraints of RFC
2298, in that they make it mandatory to return an MDN response.  As far as
I am aware, that specification has not made it to proposed standard, and
(based on long and heated discussions in the fax working group) I have my
doubts whether such a requirement will be accepted by the IESG.

#g

------------
Graham Klyne
([email protected])