Responses in line again --
Sanjay Dalal wrote:
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.
Don't think we can allow multiple enrolments under the same identity.
You can make two assumptions: that the second enrolment is a repetition,
or that the second enrolment is an identity collision. If it is a repetition
then it's probably OK, although something odd is happening. If it is an
identity collision (and we do not have globally unique identities) then
the protocol will break irreperably. I agree, that either eventuality is
unlikely, and that in truth, through use of URLs based on the disambiguation
of domain names and proper implementation that identity collisions are
extremely unlikely, but I guess you have to accommodate all cases.
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.
I would be very disappointed indeed if you stopped
asking questions. The case I would make is: the business requirement for
participant autonomy is that independent suppliers do not want to freeze
or lock up their inventory under the control of potential customers.
This involves doing business within a time band. If that constraint is
not present then it is much less likely that the deal will be done this
way. If the supplier or service provider can define a maximum width of
the time band, then it is equally reasonable that the customer seek a minimum
time within which to pull together the legs of the deal. If that time cannot
be offered then the supplier is not a good fit. Both sides get involved
in creating an acceptable band of time.
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.
OK.
|