Re: T2 - Assertions and Questions

[Dan Weinreb <dlw@exceloncorp.com>]

   Date: Tue, 14 Aug 2001 09:57:39 -0600
   From: Colleen Evans <cevans@sonicsoftware.com>

									    However, if
   the 'chasm' is considered the end to end delivery, then a weak link is a problem.

I'm sorry, I didn't say that very well.  What I was trying to say was
that if you have two "endpoint" entities that want to communicate
reliably, and they use a protocol that provides end-to-end reliable
messaging (using the usual techniques of retransmission,
acknolwedgement, duplicate detection/elimination, etc), then they can
communicate reliabily even if they have to go through a series of hops
that are unreliable (can lose messages or duplicate messages).

   I think your point that we need to clearly define the possible, meaningful and
   realistic use cases and see how the spec matches up is very valid.  In my mind,
   there are two categories of scenarios involving intermediaries:  (1) the
   intermediary provides some value-add such as BP, translation, etc. or (2) the
   intermediary is purely a switching mechanism.  These categories also impact the CPA
   discussion in terms of where the business agreements exist (between the end points,
   the end point and intermediary hop(s), etc.)

One of the scenarios I was wondering about was an intermediary that
functions as a mutually-trusted party that adds signed timestamps to
messages.  So if A sends a message to B through this IM, B receives a
message that contains the original message from A, plus a time value,
signed by the IM, so that B can later prove (provide evidence) that
the message was generated before time T and that B received it after
time T.  This scenario has IM signing something that might have
already been signed by A, i.e. nested signing, which is not at all
uncommon in cryptologic protocols, but which doesn't seem to be
something contemplated by the existing Message Service spec.  So I
suppose this is a scenario that we do not propose to deal with.  But
one of the interesting things about it is that the fact that the
messages need to be timestamped by a mutually-trusted third party, and
the question of who we mutually trust, are really parts of a business
agreement and would therefore logically belong in the actual CPA.

But just because someone can invent a scenario does not mean that
supporting it is a requirement!  The real question is what use
cases are actually required.

-- Dan