[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [business-transaction] BTP call for email vote - 5 issues
This is a call for an email vote on the proposed issue resolutions
included below. The voting period is one week, seven calendar days,
commencing Wednesday March 13 and
closing at your local midnight on Tuesday March 19.
To vote the voting member must send an email to the chair and the recording
secretary.
chair: zpope@pobox.com
secretary: peter.furniss@choreology.com
No need to include the text of this email. Just indicate:
a) who is voting,
b) each issue being voting on, and
c) the vote for each issue (YES, NO, ABSTAIN).
d) two of the votes require and A or B choice for a yes vote.
Feel free to add comments, especially for "NO" votes.
Issue list URL
----------
http://www.oasis-open.org/committees/business-transactions/issues.html
Five Issue Resolutions Attached
- Issue 29: Redirection
- Issue 41: ENROL/no-rsp-req
- Issue 60: address-as-role or role-address
Requires an A/B choice with a yes vote.
- Issue 97: Version identification on xml namespaces
- Issue 99: PREPARE_INFERIORS and FAULT(InvalidInferior)
Requires an A/B choice with a yes vote.
--------------------------------------------------------------------
Issues
--------------------------------------------------------------------
Issue 29: Redirection
--------------------
Description
Should we specify redirection functionality in the BTP spec as a part of the
protocol or as required underlying functionality?
--------------------
Proposed Resolution
Abstract:
Eliminate the redirector and related message from the specification. Submit
this functionality to an appropriate standards group, e.g. W3C XML
Protocols. In the alternative, break it out clearly as an enhancement to
messaging services, and giving it a separate section to make separate use
easier.
Concrete changes to the Specification:
In the Redirector role desription, change the first paragraph to:
Sends a REDIRECT message to inform a Superior or Inferior that an address
previously supplied for the peer (i.e. an Inferior or Superior,
respectively) is no longer appropriate, and to supply a new address or set
of addresses to replace the old one.
Change the parenthesis at the end off the paragraph that begins "If a Superior
moves .."
(Note that the inbound message may itself be a REDIRECT message, in which
case the Redirector shall use the new address in the received message as
the target for the REDIRECT that it sends.)
Delete the paragraph "A Redirector may also be used to change the address of
other BTP actors"
In the carrier protocol binding proforma, paragraph "Implicit messages", add
"carrier-protocol mechanisms," before the first "application messages".
In the list of faults, add a row
fault-type: Redirect
meaning: The target of the BTP message now has a different address.
fault-data: Set of BTP addresses, to be used instead of the address the
BTP message was received on
In the fault list for REQUEST_STATUS and REQUEST_INFERIOR_STATUSES add
Redirect -- if the intended target now has a different address.
In the fault list for ENROL add
Redirect -- if the Superior now has a different superior-address.
In the fault list for BEGIN add
Redirect -- if the Factory now has a different address.
In the fault list for PREPARE_INFERIORS, CONFIRM_TRANSACTION,
CANCEL_TRANSACTION, CANCEL_INFERIORS add
Redirect -- if the Decider now has a different decider-address.
Align the XML with the additions for FAULT.
--------------------
Supporting Material
Redirection is needed in BTP, at the abstract level, to support implementation
approaches where a recovered actor playing Superior or Inferior roles has a
different address to its original one. If a particular carrier protocol has
support for redirection in a way that is sufficient, then a BTP binding to
that carrier can map REDIRECT to that mechanism, and the REDIRECT message
itself (as an XML or other encoding) would not appear in exchanges using that
binding.
The description of "implicit messages" in the carrier protocol binding omits
mentioning that a message may be implicit because it is mapped to carrier
construct (although this is in fact what happens that section in the SOAP
binding specifcation).
SOAP 1.1 does not have such a mechanism, and for the present bindings the
REDIRECT message is used for the Superior:Inferior relationship.
The abstract message text in 0.9.2 is aligned with this, but the Redirector
role description is not.
On the non-persistent relationships, communication is always initiated by one
actor (in role of Initiator, Enroller, Terminator, Status requestor,
Redirector) which has the address of the other (Factory, Superior, Decider,
etc.), but the target of the first message will use the reply-address (or
reply mechanisms of the carrier) for the reply and does not know the other's
address a priori. (The messages are all effectively request/response). The
REDIRECT message is therefore not used on these relationships.
However, since the actors on the non-peristent relationships can also move
(often because they are also Superior or Inferior), a new FAULT/redirect can
be used as a response to any of the request/response messages, carrying a list
of one or more replacement addresses.
--------------------------------------------------------------------
Issue 41: ENROL/no-rsp-req
--------------------
Description
Page 19, first paragraph: "ENROL/no-rsp-req" - First time this short-hand has
been used. It should be described before this point.
--------------------
Proposed Resolution
No change.
The MESSAGE/parametervalue notation is described in the "Typographic and
linguistic conventions" section at the beginning of the spec.
--------------------------------------------------------------------
Issue 60: address-as-role or role-address
--------------------
Description
The abstract message descriptions call the address parameters
"address-as-superior", "address-as-inferior", "address-as-decider", intending
to be clear that these are addresses the actor in question offers for that
role (i.e. as the target of particular future messages), given that the actor
may also offer other addresses for that role (or indeed the same address, but
for a different role)
The xml constructs call these "superior address" etc., which is shorter, and
perhaps more message-oriented. (a PREPARE for example travels from the
Superior (for this relationship) to the address-as-inferior of the Inferior of
the relationship.
The names should be aligned or the difference justified in the text.
--------------------
Proposed Resolution
Solution A:
Use the form "address-as-<role>" consistently throughout the text
including the XML.
Solution B:
Use the form "<role>-address" consistently throughout the text including
the XML.
--------------------
Supporting Material
The first vote on this issue proposed the use of the form "address-as-role".
That vote ended 27 Feb 2002 with result 6 for, 9 against.
--------------------------------------------------------------------
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
--------------------------------------------------------------------
Issue 99: PREPARE_INFERIORS and FAULT(InvalidInferior)
--------------------
Description
When calling PREPARE_INFERIORS (CONFIRM_TRANSACTION), a list of inferior ids
is supplied. Now, if any of these inferiors is invalid, the spec. currently
says that the InvalidInferior FAULT is generated. However, that's all it
says. This leaves it open to implementation specific interpretation (the list
below is not meant to be complete):
(i) I could check all inferiors prior to issuing prepare on any of them and
only go ahead if all ids in the list are valid.
(ii) I could simply walk down the list and issue prepare and stop when I get
to an invalid id. However, what happens to the inferiors I haven't
talked to yet and what do I do with those I have.
(iii) I walk down the list and issue prepare and remember if I see any
invalid id. At the end of the list I return the appropriate FAULT.
(iv) modify the status-item field such that it is possible to identify which
id was invalid.
Note from Peter: Now I have a preference as to which I think we should do, but
the real reason for this message is to try to get some agreement on a standard
approach that we can put in the specification. (BTW, I think (iv) would be a
useful enhancement anyway - if I send a list of 1000 inferior ids and only one
of them was invalid it would be good if I could get that id (or list thereof)
back on the fault message.)
--------------------
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
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".
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.
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".
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.
====================================================================
BT TC Voting Rules
-------------------
Only eligible members of the TC can vote. Every member of a TC has a
single vote. Organizations do not vote in TCs. Proxies are not
allowed in TC voting.
Votes on technical and editorial issues pass when a majority votes in
favor. The majority is more than half of the members who vote on the
issue, quorum is required. Abstention are recorded and count towards
quorum. If a majority is not achieved the motion will be rejected.
If quorum is not achieved it shall be as if the motion was not
proposed and the vote did not happen.
The chair may propose draft resolutions to the members of the TC for
discussion by mail, to entertain friendly amendments to such draft
resolutions and make such changes as shall seem most likely to gain
general assent of the members of the TC, to put such resolutions as
seem to have gained majority assent to the members of the TC for a
vote by mail, and to conduct votes on such resolutions by mail.
Regards,
TC chair
William Z Pope
zpope@pobox.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC