RE: Reposted Comments on SCMP ( by Graham Klyne )

At 08:35 28/05/99 -0700, Jason Eaton wrote:

>We currently do not use the MIME "from field", however you are correct. It
>is redundant. As far as which name to use, the only name that matters is
>the name in the signature. If we retain these headers we should mention in
>the draft which value is the definitive one.

Strictly speaking, "From:" is not a MIME (content-describing) field, but an
RFC822 (e-mail) field.  As such, I think it's use and role is independent
of the definition of a protocol that aims to be independent of the
underlying message transfer used.

(Even so, a comment to the effect that it should not be used may be helpful.)


[...]
>>An easily readable name gives instant knowledge to an attacker of the 
>>existence 
>>of a relationship between the sender and receiver. Easily
>>readable SCMP control fields further identifies the relationship as a 
>>financial 
>>one. Simply collecting this type of information and publishing
>>a "Customer/Account holder List" could be very damaging to the public
>image of 
>>a financial organisation like a Bank.
>>
>
>Oops, another good argument for the remove of clear text headers. ( i
>should have read your whole message thoroughly before replying ) 
>
>I agree ... ok. However I am worried about performance characteristics of
>this change. Anybody else have any opinions on this one?

I think that this argues that it should be possible to encrypt headers (and
may even be mandatory for some types of commerce application), but I
wouldn't want to make encryption mandatory in all cases, because:
(a) I see many possible uses of SCMP that don't need encryption (just
authentication).
(b) Mandating encryption raises technical and legal difficulties that may
deter deployment of SCMP, especially globally.
(c) I see no benefit to mandating encryption at the SCMP level when it can
reasonably be mandated at the application level, on a per
"SCMP-message-type:" basis.

>>>7.7.2 Server Errors.
[...]
>Storing the reply is necessary for the reasons you list, however the reply
>mechanism that the draft contains is a "can of worms". I believe the
>consensus is to remove the ability of the protocol to return a previously
>sent reply and instead return an error.

Can this be either/or, possibly on a per-application basis?

Or, to put it another way, even if the protocol prohibits a server from
re-sending a reply, the same effect could be seen if e-mail is being used.
Consider:

C: Send request
S: Send response
   (response is delayed)
C: Resend request
S: Send error response
   (original response is delivered)
   (error response is lost)

This is, admittedly, a pretty far-fetched example.  But an e-mail based
application environment must be able to deal with such cases.  Therefore, I
see no benefit in having a prohibition on a server resending a response if
that is safe in other ways.

Actually, I think this can be cut several ways:  I think the main issue is
to consider the allowable patterns of client/server interactions in the
face of network errors, etc., and use that decide the allowable client AND
server behaviours.

   
>Bartley, the draft recommends the use of signed/enveloped. Are you
>proposing that we make it a MUST and also remove the signed only
>requirement as well?

I think it's clear from above, and other comments of mine, that I don't
favour such an approach.  But I see SCMP as potentially being about more
than just commerce.

#g

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