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

[Mark Little <mark_little@hp.com>]

BTW, the 108 issue was never to do with CONTEXT_REPLY and you are correct -
this should have been a separate issue from you. We do not believe that the
current text specified as a solution to 108 is a solution. If we have to
re-raise this as another issue then sobeit. Without a full and complete
solution to the *original* 108 issue statement from me, cohesions are not
useable.

Mark.

----- Original Message -----
From: "Peter Furniss" <peter.furniss@choreology.com>
To: "Mark Little" <mark_little@hp.com>; <zpope@pobox.com>; "OASIS BTP (Main
List)" <business-transaction@lists.oasis-open.org>
Sent: Friday, April 12, 2002 11:07 AM
Subject: re - BTP Issue 108 (was RE: [business-transaction] Email votes - 7
Issues - Ends Tues April 9 = RESULT)


> (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
>
>