[business-transaction] Call for email votes - 4 issues - ends March 27

[William Z Pope <zpope@pobox.com>]

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