OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

business-transaction message

[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