RE: [business-transaction] BTP call for email vote - 5 issues

[William Z Pope <zpope@pobox.com>]

 

Right, on issue 60.  If there had been clear concensus for either option we would have just accepted it.

Given the tally and the way the vote was phrased it would have assumed too much to merely accept

the "role-address" form.  So, it's re-issued in a way that allows voters to more clearly represent what

they want.

 

=bill

-----Original Message-----
From: Peter Furniss [mailto:peter.furniss@choreology.com]
Sent: Monday, March 18, 2002 10:53 AM
To: Sazi Temel; Mark Little
Cc: zpope@pobox.com; OASIS BTP (Main List)
Subject: RE: [business-transaction] BTP call for email vote - 5 issues

Bill's call is in http://lists.oasis-open.org/archives/business-transaction/200203/msg00032.html,

sent wednesday 13th at 8pm eastern

 

On issue 60, the original vote was phrased as "do you agree with address-as-role".  That had 6 for, 9 against. 6 of the against votes included "write-in"s for role-address. We decided that we shouldn't just count it as an either/or since that wasn't what the question had been.

 

Peter

-----Original Message-----
From: Sazi Temel [mailto:sazi.temel@bea.com]
Sent: 18 March 2002 14:33
To: Mark Little
Cc: zpope@pobox.com; OASIS BTP (Main List); Peter Furniss
Subject: Re: [business-transaction] BTP call for email vote - 5 issues

I am confused with this new voting.. I have no e-mail on request for votes for these issues and cannot see any in the archives (perhaps I have missed it)... Was this decided on the March 13 conf call (which I was joined a bit late) ?

Also, as Mark pointed out haven't we voted on issue 60? Thanks for any info.

--Sazi

At 01:58 PM 3/17/02 +0000, Mark Little wrote:

> Issue 29: Redirection

YES

> --------------------------------------------------------------------
> Issue 41: ENROL/no-rsp-req

YES

> Issue 60: address-as-role or role-address

I thought we had already voted on this? Why are we revoting?

My vote still stands: B.

> Issue 97: Version identification on xml namespaces
> --------------------
> Description
>
> The proposed "btp" namespace definition does not appear to provide
timestamp
> or version info.
>
> --------------------
> Proposed Resolution
>
> Change the namespace URIs for the main message schema
> (currently urn:oasis:names:tc:BTP:xml) to
>
>     urn:oasis:names:tc:BTP:1:0:core
>
> Change the standard qualifiers schema
> (currently urn:oasis:names:tc:BTP:qualifiers) to
>
>     urn:oasis:names:tc:BTP:1:0:qualifiers

YES.

> --------------------------------------------------------------------
> Issue 99: PREPARE_INFERIORS and FAULT(InvalidInferior)
> --------------------
> Proposed Resolution
>
> In the description of FAULT, in the table of fault-types change the
> InvalidInferior row to:
>
>     InvalidInferior
>
>     The "inferior-identifier" in the message or at least one
>     "inferior-identifier"s in an "inferior-list" parameter is not known or
>     does not identify a known Inferior.
>
>     One or more invalid identifiers

YES

> In the description of CANCEL_INFERIORS add:
>
>     If one or more of the "inferior-identifier"s in the "inferior-list" is
>     unknown (does not correspond to an enrolled Inferior), a
>     FAULT(Invalid-inferior) shall be returned. It is an implementation
>     option whether CANCEL is sent to any of the Inferiors that are validly
>     idenitfied in the "inferiors-list".

YES (change idenitfied to identified).

> In the description of CONFIRM_TRANSACTION add:
>
>
>     If one or more of the "inferior-identifier"s in the "inferior-list" is
>     unknown (does not correspond to an enrolled Inferior), a
>     FAULT/Invalid-inferior shall be returned. The Decider shall not make a
>     confirm decision and shall not send CONFIRM to any Inferior.

YES.

>
> In the description of PREPARE_INFERIORS add:
>
> ONE of the following paragraphs:
>
>
> CHOICE A:
>
>
>     If one or more of the "inferior-identifier"s in the "inferior-list" is
>     unknown (does not correspond to an enrolled Inferior), a
>     FAULT/Invalid-inferior shall be returned. The Decider shall not send
>     PREPARE to any Inferior.
>
> CHOICE B:
>
>     If one or more of the "inferior-identifier"s in the "inferior-list" is
>     unknown (does not correspond to an enrolled Inferior), a
>     FAULT/Invalid-inferior shall be returned. It is an implementation
option
>     whether PREPARE is sent to any of the Inferiors that are validly
>     identified in the "inferiors-list".

A

>
> In the faults lists for CANCEL_INFERIORS, PREPARE_INFERIORS and
> CONFIRM_TRANSACTION, make the the InvalidInferior line
>
>     InvalidInferior -- if one or more inferior handles in the
inferiors-list
>     is unknown.

YES.

Mark.

----------------------------------------------
Dr. Mark Little, Distinguished Engineer,
Transactions Architect, HP Arjuna Labs
Email: mark_little@hp.com
Phone: +44 191 2606216
Fax  : +44 191 2606250




----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

Sazi Temel
'                               
bea Systems Inc.        
140 Allen Road  Liberty Corner, NJ 07938
        
sazi.temel@bea.com
sazi.temel@ieee.org
(1) 908 580 3123        
http://www.bea.com