[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