re - BTP Issue 108 (was RE: [business-transaction] Email votes - 7Issues - Ends Tues April 9 = RESULT)

[Peter Furniss <peter.furniss@choreology.com>]

(Changing the subject so the script that makes the message thread links on
the issues list can spot this.)


> > The results for the issue resolution votes are included below.
> >
> > 4 61 87 100 107 108 109
> > for 13 13 3 11 11 7 9
> > against 0 0 6 0 1 4 0
> > abstain 0 0 4 2 1 2 4
> >
> >
> > - Proposed resolution of Issue 87: "Conformance" was rejected.
> > - Proposed resolution of Issue 108: "Participant and service
> identification"
> >   passed with a narrow margin, see note below.
> > - All others passed cleanly.
> >
> > There has been on-going discussion on Issue 108 on the bt-spec mailing
> list.
> > The TC has voted this resolution and it must be included in the next
> draft.
> > However there may be a need to re-address this if there is a bug and the
> > resolution does provide the fix intended.  The discussion has been
> primarily
> > between Mark Little and Peter Furniss.  I'll get a statement
> from them on
> > why they still see an issue.
>
> Bill, just as a matter of procedure it seems strange to vote on
> an issue for
> which there is outstanding work, i.e., there isn't (or wasn't) a clear
> choice for people to make since Peter and I were still passing
> this back and
> forth. Even now we haven't finished as far as I'm concerned.

I think really there were two matters:
	the original issue 108 that Mark raised (which was deferred, though Mark
asked for it to be opened)
	the bug about CONTEXT_REPLY(incomplete), that I found while investigating
108.

In retrospect, I probably should have raised another issue for the second,
and deemed it open because it was bug-fix, rather than putting it in as the
solution to 108. I don't think anyone has objected to the bug-fix, other
than to say it is not (in their/your view) necessarily a sufficient solution
to 108.

Had I created a new issue, 108 would then have the proposed solution (from
me) of "no change", but would be pending a vote to open anyway (which would
amount to the same thing)


On 108 itself, I would assert:

the concerns are really application protocol issues, not BTP ones. More
precisely, they
are concerns of BTP-using applications, and therefore need to be addressed
in the
specification of the application+btp contract between the parties.
"applications" in this sense includes the btp-supporting infrastructure
(such a interceptors/filters etc that deal with the application messages,
containers or whatever that keep track of thread-associated contexts, and
transaction-conscious resources that determine what enrollments are
necessary)

no change is needed in the normative spec; the existing fields and
qualifiers provide the necessary information signals between the parties
involved - there are unambiguous identifiers that can be quoted by
application (or application-associated) messages, and there is an
application-determined inferior-name that can be as precise as is pleased.

Explaining how to define an application+btp contract/protocol is not
something that needs to be in the spec itself. I'm not at all sure we know
all the ramifications (in fact, I'm quite sure we don't), still less agree
on them. Some of this is going to be in user guides for BTP-using products.
It might be specified in some way in WSDL or similar, that stated the
expectation and nature of a service.

Peter

------------------------------------------
Peter Furniss
Chief Scientist, Choreology Ltd
web: http://www.choreology.com
email:  peter.furniss@choreology.com
phone:  +44 20 7670 1679
direct: +44 20 7670 1783
mobile: +44 7951 536168
13 Austin Friars, London EC2N 2JX