[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [business-transaction] BTP call for email vote - 5 issues
-----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 issuessent wednesday 13th at 8pm easternOn 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 RoadLiberty Corner, NJ 07938
sazi.temel@bea.com
sazi.temel@ieee.org
(1) 908 580 3123
http://www.bea.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC