Re: Comment on draft-arnold-scmp-02.txt [repost 1 of 2]

[Reposting 1 of 2, from a previous discussion]


At 14:22 06/05/99 +0000, John Stracke wrote:

[...]
>> We don't want to specify the payload. As we use the protocol for serveral
>> different payloads.
>
>OK, understood; I just think that, if SCMP were adopted as a standard, the
>payloads would have to be specified in standards documents, or you
wouldn't have
>any interoperability without private agreements (which don't scale, which
is the
>problem that standards are meant to address :-).

I think different viewpoints are possible here, exemplified by the
difference between the positions we take.

I see SCMP as a potential component part of a range of applications that
have common requirements for non-repudiated message delivery, just as SMTP
or HTTP are used as components of e-mail and the WWW;  they do not suffer
for lack of a defined payload type.

I think at the core of this debate is whether one wishes the SCMP
specification to describe a total solution:  to my mind it is clearly not.

I do agree with your comments about scalability of "private agreements",
but there are other ways to address that issue.  For example, Internet fax
is a standard that defines a payload format (among other things) used with
SMTP.  I would hazard a guess that, in time, CyberSource may wish to
publish a specification that describes a commerce application running over
SCMP:  that specification would define payload formats, etc.

This raises a question: should SCMP have some kind of application discovery
mechanism?  E.g. SCMP-message-type: Identify-capabilities, to which the
response is required to indicate (in some defined way) a list of message
types supported by the receiving server.

>> >7.1.2: it seems to me that the mechanisms described in the subsections
>> >here are policy rather than protocol.
>>
>> Should we not specify policy?
>
>I would think not.  You may want to make recommendations, probably in the
>Security Considerations section; ...

I agree.

>> >7.2.1: since serialization is probably an important feature (without it,
>> >you can't do pipelining), why not specify it? It'd be pretty easy:
>>
>> Yes we thought of supporting this. Part of the problem is that we have a
>> working implementation of this here at CyberSource now.
>
>Ah, I see.  That was not apparent when I read the draft; and, yes, that
makes a
>big difference.

I think that lumbering all implementations with this requirement is not
necessarily helpful.  And it goes against the desire to minimize state in
the protocol.

On the other hand, I don't see that serialization needs to be prohibited
for all applications of SCMP.

>> I know this is a business excuse, but I think with this version of the spec
>> we can live without multi-part message support. Can we save it for the next
>> version?
>
>Fine.

I think that would go against the payload-neutral aspects of the protocol.  

I would see serialization of multiple operations within a single
request/response as related to payload semantics rather than protocol
semantics.

>> >8.1: can this format support Unicode error messages?
>>
>> I don't see how the spec would not allow this.
>
>But it doesn't support it, either.  You say that an error response is
>"SCMP <error code> <error message>"; but you don't specify its MIME type or
>whether it can carry charset and language parameters.

I felt this too.  But closer reading of the spec made it clear that no
specific semantics (language or otherwise) were associated with the text,
so to get into language and charset tagging issues introduces complexity of
dubious value.

The whole issue of error text is rather vague:  I'd suggest that any text
should use UTF-8 charset (so presentation is not a problem), and that some
commentary be added to suggest that it is used to supply additional
information relating to an error condition (e.g. filename, application
name, internal status information) that may refine the error diagnostic
rather than to describe the error condition.


#g

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