[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
Issue 29: Redirection NO. I would keep the current approach AND submit additional functionality to the W3C - XML Pipelining being a strong possibility. - Issue 41: ENROL/no-rsp-req YES. - Issue 60: address-as-role or role-address Requires an A/B choice with a yes vote. YES B. - Issue 97: Version identification on xml namespaces YES. - Issue 99: PREPARE_INFERIORS and FAULT(InvalidInferior) Requires an A/B choice with a yes vote. YES B. William Z Pope wrote: > 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 > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl>
begin:vcard n:Brown;Geoff tel;cell:415 298 7580 tel;work:650 506 3230 x-mozilla-html:FALSE org:ATS - Core Technologies;Oracle Corporation adr:;;;;;; version:2.1 email;internet:Geoffrey.Brown@oracle.com title:Technical Director fn:Geoff Brown end:vcard
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC