[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [business-transaction] Call for email votes - 4 issues - endsMarch 27
Issue 29: Redirection (revote) YES. Issue 96: Reply address on SUPERIOR, INFERIOR_STATUS YES. Issue 98: MIME-Version should not be HTTP header YES. Issue 106: Free text for all FAULTs YES. 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 days, commencing Thursday March 21, 2002 > and closing at your local midnight on Wednesday March 27, 2002. > > 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). > Feel free to add comments, especially for "NO" votes. > > Issue list URL > ---------- > http://www.oasis-open.org/committees/business-transactions/issues.html > > Issue 29: Redirection (revote) > Issue 96: Reply address on SUPERIOR, INFERIOR_STATUS > Issue 98: MIME-Version should not be HTTP header > Issue 106: Free text for all FAULTs > > Issues > -------------------------------------------------------------------- > > Issue 29: Redirection > This issue is being re-voted because of errors in the proposed solution text > of the previous ballot. > > -------------------- > Description > > Should we specify redirection functionality in the BTP spec as a part of the > protocol or as required underlying functionality? > > -------------------- > Proposed Resolution > > 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 96: Reply address on SUPERIOR, INFERIOR_STATUS > > -------------------- > Description > > Reply address should be added to the parameter list when reply requested=true > The *_STATUS messages can be sent when the receiving side has no knowledge of > the location or identity of the partner. If a reply is needed (it will be the > /unknown), the responder needs to know where to send it. > > -------------------- > Proposed Resolution > > Delete the last paragraph in the section Abstract Messages, Request/response > pairs and insert: > > Between Superior and Inferior the address of the peer is normally known > (from the "superior-address" on an earlier CONTEXT or the > "inferior-address" on a received ENROL). However, in some cases a message > will be received for a Superior or Inferior that is not known - the state > information no longer exists. This is not an exceptional condition but > occurs when one side has either not created or has removed its persistent > state in accordance with the procedures, but a message has got lost in a > failure, and the peer still has state information. The response to a > message for an unknown (and logically non-existent) Superior is > SUPERIOR_STATE/unknown, for an unknown Inferior it is > INFERIOR_STATE/unknown. However, since the intended target is unknown, > there is no information to locate the peer, which sent the undeliverable > message. To enable the receiver to reply with the appropriate > *_STATE/unknown, all the messages between Superior and Inferior have a > "senders-address" parameter. If a FAULT message is to be sent in response > to message which (as an abstract message) has a "senders-address" > parameter, the FAULT message is sent to that address. > > Note - Both reply-address and senders-address may be absent when the > carrier protocol itself has a request/response pattern. In these > cases, the reply or sender address is implicitly that of the sender of > the request (and thus the destination of a response) > > Add a "sender-address" parameter, with type BTP address to the following > messages: ENROLLED, RESIGN, RESIGNED, PREPARE, PREPARED, CONFIRM, CONFIRMED, > CANCEL, CANCELLED, CONFIRM_ONE_PHASE, HAZARD, CONTRADICTION, SUPERIOR_STATE, > INFERIOR_STATE. The explanation for the parameter is: > > sender-address the address from which the <message> is sent. This is an > address of the <Superior|Inferior>. > > substituting appropriately. > > For these messages, where there is a FAULTs paragraph, change the text to > "... (sent to "sender-address") > > In the XML definitions add to the messages listed above: <code> > <btp:sender-address> ...address... </btp:sender-address> > > In Carrier Protocol Bindings, Bindings for request/response carrier protocols, > add at the end of the third paragraph: > > These rules also allow the receiver of a message between Superior and > Inferior (in either direction) on a carrier protocol request to send any > reply message on the carrier response - the "sender-address" field is > implicitly considered to be that of the sender of the carrier request. > > In the following Request/response exploitation rules, change the fourth > paragraph to: > > Within the outcome relationship, apart from ENROL, there is no > "reply-address", and the parties normally know each other's > "superior-address" and "inferior-address". However, these messages have a > "sender-address", which is used when the receiver does not have knowledge > of the peer. In this case, the "sender-address" is treated as the > "reply-address" of the other messages - if the field is absent in a > message on a carrier request, the "sender-address" is implicitly that of > the request sender. Any message for the peer (including the three messages > mentioned, FAULT but also any other valid message in the Superior:Inferior > relationship) may be sent on the carrier response. Apart from this, both > sides are permitted to treat the carrier request/response exchanges as > opportunities for sending messages to the appropriate destination. > > Add a new rule: > > d) A BTP actor that has received, on a carrier protocol request, one or > more BTP messages or related groups that, as abstract messages, have a > "sender-address" parameter but no "reply-address" was supplied and does > not have knowledge of the peer address, must bundle the responding BTP > message and groups in a btp:messages element and transmit this element > on the carrier protocol response to the request that carried the BTP > request. If the actor does have knowledge of the peer address it may > send one or messages for the peer in the carrier protocol response, > regardless of whether the binding address of the peer matches the > address of the carrier protocol requestor. > > -------------------------------------------------------------------- > > Issue 98: MIME-Version should not be HTTP header > > -------------------- > Description > > In the example, "MIME-Version: 1.0" header must not appear in HTTP header > according to http://www.w3.org/TR/2000/NOTE-SOAP-attachments-20001211 > > -------------------- > Proposed Resolution > > Delete the MIME version line at the head of the example. > > -------------------------------------------------------------------- > > Issue 106: Free text for all FAULTs > > -------------------- > Description > > I would much prefer free text explanations were directly supported by the > FAULT message. That would reserve fault-data for additions specific to a fault > type and allow additional text no matter what the problem. My preferred > resolution would add a free-text parameter (or some such) to the FAULT message > and remove "Free text explanation" from the fault-data column wherever > specific material isn't required. > > -------------------- > Proposed Resolution > > Add a new parameter to FAULT "fault-text", with explanation: > > fault-text Free text describing the fault or providing more > information. Whether this parameter is present, and exactly what it > contains are an implementation option. > > Where "fault-data" is currently "Free text explanation", change it to "None" > > Make the same changes in the XML. > > ==================================================================== > > 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