|
Alastair,
Please see my response inline.
sanjay
----- Original Message -----
Sent: Thursday, August 23, 2001 9:15
AM
Subject: Re: anonymous participants -
CONTEXT_REPLY & VCT
Sanjay,
A belated response (I had to go to Mark Little's wedding over the long
weekend, so am catching up).
Congratulations to Mark Little.
Sanjay Dalal wrote:
I believe we can make
this a property of the Atom/Cohesion. One example is, I am just making this
up, an electronic gun market exchange or electronic drug trafficker, where
buyers and sellers would like to remain anonymous. May be this is not a real
world scenario, may be it is and I don't know :), FBI can track a lot of
things nowadays. Anyway, is it a good idea to mark Cohesions or Atoms
"anonymous"? In that case, some of the messages like INFERIOR_STATUSES won't
be relevant as identity of a participant is not revealed by
Coordinator/Cohesion. What do you
think?
I think that there
will a null value for this identifier, if the element is absent or has a
nil="true" attribute (whichever is decided). In that case the Enroller has
decided that it doesn't want to bother to identify the Inferior (or that it
wants to hide its identity, although the address information it must provide
makes that difficult). The INFERIOR_STATUSES message will be useful and
necessary, however, either for auding purposes, or (in the case where the
Composer has kept track of its Inferior's identities independently) for
deciding cohesion outcomes.
I realized after sending
this that addresses make it difficult to hide identities. Anyway, forget
about it.
3)
Index <snip>I
think we need a rule that states that an Inferior enrolment received by a
Superior is invalid if it presents a duplicate Inferior Identity to one
already enrolled with the Superior. This implies a state table change that
ensures that FAULT is returned in this attempt is made.
I believe we should
allow multiple enrollments if CANCEL is not received between 2
enrollements for the same atom from the same inferior. However, if CANCEL is
received between two enrollments for the same atom from the same
inferiror, then throw FAULT on subsequent enrol requests.
4)
What might be the business reasons for the
following? Do you have any practical applications in mind? If there is
no pressing need then we should avoid putting such additional qualifiers in
the protocol.
...This was intended to send a demand
to the Inferior: if you cannot promise to hold off auto-cancellation or
confirmation for n seconds, just send me CANCELLED.
We would also like to see another
standard qualifier on PREPARE which would enable the Superior to state "I
will not accept any autonomous nonsense from you: send me CANCELLED if you
cannot agree to this", which can be refined to "do not auto confirm"/"do not
auto cancel"/"don’t do either" of which the most interesting is "don’t auto
confirm", I think.</ag>
I disagree. First of all, it was
already discussed and decided at Mt Laurel, as I pointed out. It is a
relatively painless complement to the Inferior qualifying its READY. It
requires a very small amount of code on the receiving side, and need not be
sent or allowed on the sending side in a particular
implementation.
I was wondering you will give business reason(s)
:). You can make something up as I did before ;), but please don't
take this question wrong. I am just trying to weed-out complexity
arising due to n possible events and where time element is involved...
I promise that I won't stop asking such questions...someone has to
do it.
Lastly, CONTEXT_REPLY approach a) (I never found
it in doc but I assume that it is the one described the first) does not
guarantee a very basic argument I was making in SJ meeting "Service should
not even know about the atom if enrol for that Service is not successful." I
think this is a very essential point. Here is
why...
Okay, I (more or less) rest my case
on this issue based on arguments given by you and Mark Potts. We can achieve
this by intercepting through Communicator. I am beginning to realize though
that Communicator will be a necessary actor and
Coordinator/SubCoordinator/Participant actors will have a "isA" relationship
with Communicator in a lot of (or most of) implementations. BTW, my first
argument was weak anyway as I won't choose enrollment over non-repudiation to
prevent fraud.
|