[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