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

[Mark Little <mark_little@hp.com>]

> 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